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)

Talking to 2 different hipchat rooms to use your own plugin as an example.

The alternative is to implement multiple equivalent web hooks - hipchat1, hipchat2, .... Adding extra logic to the implementation of a single hook is just extra work and more difficult to configure plus they cannot be enable and disabled separately. I think the JIRA analogy is still the most relevant.

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.