Limit webhook trigger on specific branch

[Cesar-convendia]

I have setup a webhook in Bitbucket to trigger a jenkins build on every push.

The issue is that my jenkins build itself will make create a tag for the release candidate and pushes it to bitbucket.

This creates an infinite loop of builds.

Is there a way to limit the trigger to a specific branch? For example the webhook triggers on a push to master but not when a tag is pushed.

[abhin-atl]

Hi Cesar,

Is there no way for you to change your build such that it only pushes a tag to Bitbucket for a specific branch? The webhook from Bitbucket has to include the name of the branch.

I'm no PM, but I would imagine that one has more flexibility to write scripts how they please on the Jenkins side and hence perhaps the challenge of filtering branches is better tackled there.

[Cesar-convendia]

Hi Abhin, thanks for your help.

I'm not sure what you mean by pushing a tag for a specific branch. In Git tags are objects like commits and branches. Pushing can involve any of them.

Jenkins has a REST API that allow you to trigger a build. Once the call to the API is made, it will trigger a build. 

I'm using the cloud version of Bitbucket and I can't specify a branch name for the trigger:

Screen Shot 2016-07-12 at 07.10.21.png

I'll continue looking for a way to prevent Jenkins from building on trigger if the desired branch has not changed.

[abhin-atl]

Hi Cesar,

I totally didn't phrase that right. What I'm getting at is that when Jenkins starts a build (after being triggered by a BB webhook), it must run some script that you wrote that then does the tagging (and pushing). From what I understand, the problem you're facing is that push from the build triggers yet another webhook etc. But I suspect that you can break the loop from your own script using some sort of pre-condition that must be satisfied before your script decides to tag the release candidate and push the tag. 

Does you build script have access to the payload of the webhook? If so, the payload contains what was pushed. You should be able to then notice that the push only contained a tag and that the name of the tag matched the pattern you must use for your release candidates. Based on that pre-condition, you could choose to not tag again and push the tag.

Please let me know if that works for you.

[Pablo Sanchez]

I solved this problem by forcing people to commit with a tag like 

[CI]

So I have a git check step that checks the last commit. If it has [CI] it continues and do all the voodoo tricks to commit, transit, comment in ticket from the pipelines, but if it doesn't I do an

exit 0

The pipeline is stopped and I also save lots and lots of minutes triggered by "backup" pushes. :-) 

[emards]

Hello

There does not seem to be an answer because I have looked for the same information but never found a solution.