Closed faiyat closed 10 years ago
The blacklist feature won't stop Jenkins from building the branch. It only prevents the plugin from sending the notification to Jenkins when a commit has been made to that branch.
If another commit comes behind it at some other time to a non-blacklisted branch, a notification will be sent to Jenkins. Jenkins will then see ALL of the updates (to both the blacklisted and non-blacklisted) branches and start builds for each. You will need to configure your Jenkins project to only perform builds on certain branches in order to achieve the result you're looking for.
Thanks for your quick reply, Michael. But what's the use of this feature then?
Haha... good question. Someone had requested the ability to whitelist (Issue #58), so I built out the code for that. The requesting user has a use case there, so that might shed a little light. Since it was almost no difference to blacklist or whitelist, I went ahead and added the ability to blacklist.
So if I configure Jenkins job to only build from personal/* feature/* etc branches, but there are changes in master, production, etc branches, will Jenkins still randomly build any/all personal/* feature/* branches instead even there are no changes on these branches?
Jenkins only builds for branches in which there are changes.
Mike, keep me straight here...
When a change happens in Stash on a whitelisted/non-blacklisted branch in a repo, Mike's plugin tells Jenkins "dude, a change occurred in this repo", and that's basically all it says. It is not notifying the commit number or anything.
In Jenkins, it takes that repo name, finds all build jobs pointed at that repo, and they all poll. Thus, any build jobs that exist will then see any and all changes on the branches the jobs are configured to watch.
That is the current workflow, yes. Jenkins does exactly what you described.
There is a request to use the new (although it's been out for a little while) ability to specify the actual branch and hash for the commit. This will then only perform that specific commit (theoretically anyways).
You mean, the plugin would include repo+branch+commit, and then Jenkins would only match up jobs to poll using all three pieces rather than just by repo?
That's what the feature request is for, as the Git Plugin in Jenkins now supports that. However, I haven't started to do any of the work involved with that yet.
Ok. I've updated the Jenkins job to build from only the non-blacklisted branches. The combination of the webhook blacklist and Jenkins job configuration has helped achieved the idea result I was hoping for, that is only build from the branches I specified. Since this is no longer an issue, you may want to close this one. In addition, would you mind updating the document with this information as I think there might be someone like me confused on the same issue here.
Excellent. I'll update the documentation. Thanks for the feedback and for the discussion on the issue. I'm going to go ahead and close this for now, but feel free to comment if you have more to discuss. :)
We have configured 'Ignore from' option of this hook with value of 'master production release/* integration/* sandbox/* ' , but all of these branches are still being built for every new change detected in git repository. Tried look into the source code, but still clueless. Does it work for anyone?