cpeterson, I've raised a separate issue for providing web hooks within Stash. There is a use case for generic web hooks and hopefully we'll be able to cater for them in the future.

EDIT: Forgot to link the issue from the comment: STASH-3247

Is there any chance atlassian will make a generic plugin to make a POST request to a specified url? The stash-example-async-post-receive-config example plugin has almost exactly what I need, but unfortunately I am not particularly savvy about how to build and install such a thing. It seems generally useful enough that I am surprised it was not one that was included out of the box.

In our current setup, we have multiple jenkins environments. In the commit hook i checked the directory and based on the directory i would issue a call towards <jenkins>/git/notifyCommit?url=ssh://<repodir>

Since this is now on project based naming, there is nothing i can really use to indicate to which server it should go. How should i handle this? Perhaps add a group to the project to indicate to which jenkins instance it needs to go, but i've not seen any handy "things" in this regards.

bob.swift I certainly agree that it will be more work for hooks where this makes sense. But for the first implementation we've decided that this would be acceptable.

In your HipChat example it might be easier to configure a single hook and have the ability to select multiple rooms. That way you only need to configure the authentication token once.

In Stash we strive to not over-engineer solutions to problems if we can't think of a number of good use-cases that justify the investment. In this case, we couldn't think of many use-cases and opted for the single hook solution. If this assumption turns out to be wrong, we are happy to revisit the implementation at a later stage.

Hope this makes sense and thanks for the feedback.

It's an example of where it's been implemented in this way. But which service do you think should be contacted twice?

I think the best example would be Bitbucket's Services integration (https://confluence.atlassian.com/display/BITBUCKET/Managing+Bitbucket+Services).
You can add the same service multiple times. Each one with a different configuration. (Screenshot: http://d.pr/i/uVKj)

Bob, can you describe your use case in more detail? Apart from pinging a URL, we couldn't think of many use cases for having multiple hooks of the same type.

Therefore we've decided toward it up to the hook to cater for multiple fields. For example, if you want to ping multiple URLs, the hook itself could provide multiple text fields.

If there turn out to be a ton of use cases for this, we are open to change this behavior at a later stage.

Here's an example use case for what Bob is saying:

You have an example plugin for a post-commit hook that pings a URL (taken from the configuration form). If I wanted to ping multiple URLs I would need to modify the plugin to accept more than one, I couldn't have the same plugin run twice with two different configurations.

While it is possible to modify this example easily enough (make the input a text field and loop through URLs) it might not be so simple for more complex plugins and it means the developer has to have this use case in mind.

I understand that part, I already have my skeleton implementation. The problem is that you cannot have 2 of the same type and use configuration to distinguish what they do. In JIRA, you can add a function as many times as you need. Each one is configured separately.

Hi Bob,

I'm not completely familiar with how JIRA conditions and post functions work but I believe it is a similar concept for Stash repository hooks. If you haven't already I would suggest having a look at the following blog and HOW guide:

http://blogs.atlassian.com/2013/03/stash-git-hooks-api/
https://developer.atlassian.com/stash/docs/latest/how-tos/repository-hooks.html

Basically you create a java class and optionally a configuration form. When the hook is invoked it is passed the configuration defined for that hook for that repository. Each hook can be enabled/disabled and configured at a repository level.

I think of commit hooks like JIRA conditions/validators/post functions. In JIRA I can add the same function more than once and use configuration to do different things. I can't figure out how to do this with Stash commit hooks. Am I missing something?

For those wanting to write hooks, they are implemented as plugin modules that are installed within Stash then enabled and configured on a per-repository level.

See our plugin developer blog for more details.

Stash pre/post-receive hooks are now available in Stash 2.2. Read all about it in our release blog:

http://blogs.atlassian.com/2013/03/stash-22-customize-workflow-git-hooks-api-merge-checks

I think it might be nice to be able to register specific pre-receive hooks within the Stash UI, and then assign them on the fly to various repositories/projects. Something like a checkstyle pre-receive hook is tedious to setup and maintain when you have to add the script manually the repositories that need it.

Same goes with post-receive. As the number of repositories increases, proper management of the scripts (and rapid deployment) would be a great addition for admins.

+1 for Justin's approach to make a URL call (trigger jenkins build, automation workflow, etc).

We have multiple jenkins instances, i use in our current solution the git directory to assign them to different instances. Would be nice to set per project the url or something similar.

A little confusing here. Commit hooks executed under client side. Only 'pre-recieve', 'post-recieve' and 'update' hooks performed on server. See http://git-scm.com/book/en/Customizing-Git-Git-Hooks#Server-Side-Hooks

In fact if this request about Web Hooks (like in GitHub) it will be very nice to implement it feature by correct way, to really just coping GitHub. The GitHub how did not allow to implement pre-recieve hook at all. Is Stash allow users to define pre-recieve and post-recieve (update) hooks it will be one of great Git managements solutions.

A lighter approach is letting users specify URLs that will get called as a commit-hook. This avoids code running on the server and any complicated UI to specify the running of arbitrary code. Having Stash only call a URL as a post-hook gives solves 90% of the problem with only 10% of the work.

Hi jgriff,

I've raised a feature request for you at STASH-2841. We think a tight integration with Bamboo is a great idea and hope to be delivering a solution in the near future. Please feel free to vote on the mentioned issue.

Jason Hinch,
Stash Java Developer

As a neat idea, it would be cool to see tight integration with Bamboo here. A tailored UI for configuring a hook for notifying Bamboo, where it just asks you for the location of your Bamboo instance and the plan ID to notify.

Some ideas for Commit Hooks:

1. Stop people from merging master onto some other branch (e.g. branch used to release bug fix release). Seems to happen to teams from time to time and is a total mess to untangle.
2. Stop push force as this can lose history (chat to Matt Quail about details if needed)

We also want to use pre-commit hooks to do some basic sanity checking before allowing code into our master as well as prevent commits when a build is broken ala continuous delivery.