Build only the Git branch that has been pushed to

Question

I have a Jenkins job to build the master branch of my GitHub repo. It triggers nicely when I push a commit to master, and I'm very happy about it.

I would also like to have a single Jenkins job that would build any other branch in this repository. I.e. whenever I push a commit to a branch (that is not master), I'd like to have this Jenkins job to build that branch, and only that branch.

Using the GitHub pull-request plugin requires me to create a pull-request, and merges my commit with master. I'd like to do this without having to create a pull-request, and to only build my commit without merging it with master.

Setting up the Git plugin to build all branches means that whenever I push to master, all branches are built. I'd like to only build the one branch that has been modified.

Is this possible to do in Jenkins?

Answer 1

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.