Build only the Git branch that has been pushed to Build only the Git branch that has been pushed to jenkins jenkins

Build only the Git branch that has been pushed to


I was having the same issue so I set up a dummy project to experiment and found the solution. And found that yes, you can build only the branch that's been pushed into.

The short answer is to use a "Branch Specifier". For instance origin/feature**.

If you're using the GitFlow and all your feature branches are named with a feature/ prefix, then this is the solution.

And if you're curious here's how I figured it out.

From the repository's settings I set the service “Github plugin” with the Jenkins hook https://<jenkin server>/github-webhook/.Note that, at least for me what happened was that for some reason after pressing "test", the message of the payload being sent never changed to confirm it was received/acknowledged or anything. Maybe there’s no reply. It's confusing, but anyway...

I created a new Jenkins job and set the branch specifier to blank -which Jenkins then automatically sets to **.

I created a feature branch feature/foo and pushed into it.

  • Build 1 was fired, but on the master branch.
  • Build 2 was also fired on the feature/foo branch.

So it seems with the ** or blank specifier the plugin will fire builds on all branches of a repo whenever there’s a push to any of them.

Then I tried with pattern refs/heads/feature/foo and pushed another change to the feature/foo branch.

  • Build 3 was fired on the feature/foo branch.
  • No other builds were fired.

Sort of ok, but this is too rigid. It would force us to have one build job for each feature branch. I wanted one build job for all feature branches.

Then I tried a wildcard with pattern refs/heads/feature\*\* and pushed changes to feature/foo.

  • No build was fired.

Then I tried branch specifier refs/heads/feature/\*\* and pushed.

  • No build was fired

Then I saw the help of the "Branch Specifier" field reads this under the "Wildcards" section:

The syntax is of the form: REPOSITORYNAME/BRANCH. In addition, BRANCH is recognized as a shorthand of */BRANCH, * is recognized as a wildcard, and ** is recognized as wildcard that includes the separator /. Therefore, origin/branches* would match origin/branches-foo but not origin/branches/foo, while origin/branches** would match both origin/branches-foo and origin/branches/foo.

So I tried origin/feature**

  • Build 4 was fired on origin/feature/foo.

Eureka! Seems you can’t use wildcards with the references (starting with refs/), but you can with the names of the actual branches (starting with origin/).

Then I created branch feature/bar and pushed to it. To verify that only this one would be built and not other branches also starting with feature/.

  • Build 5 was fired on origin/feature/bar.

Looked almost there. Just needed a few more tests.

Then I pushed another change to origin/master

  • No build fired. Great!

Then I pushed another change to feature/bar, to test that only this branch would be built. Despite the fact that origin/master had also been pushed into.

  • Build 6 was fired on feature/bar.
  • No other builds fired.

Looks good to me.


You can see there plugin of multiple branch configuring with Jenkins. Getting feedback for any branch from Jenkins is possible with that method.

https://wiki.jenkins-ci.org/display/JENKINS/Multi-Branch+Project+Plugin

I hope it may help.


Found there's an whitelist config listed in Build Trigger section:

click advanced to expand all options

whitelist

There you can specify to build/test which branch the PR will be merged into.