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.
Found there's an whitelist config listed in Build Trigger section:
There you can specify to build/test which branch the PR will be merged into.
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.
master branch.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.
feature/foo branch.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.
Then I tried branch specifier refs/heads/feature/\*\* and pushed.
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,BRANCHis recognized as a shorthand of*/BRANCH,*is recognized as a wildcard, and**is recognized as wildcard that includes the separator/. Therefore,origin/branches*would matchorigin/branches-foobut notorigin/branches/foo, whileorigin/branches**would match bothorigin/branches-fooandorigin/branches/foo.
So I tried origin/feature**
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/.
origin/feature/bar.Looked almost there. Just needed a few more tests.
Then I pushed another change to origin/master
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.
feature/bar.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.
you can easily specify branch in job configuration:
in section Source Code Management where you have already specified your git repository URL you have also an option to specify branches to build. Simply please a name of your branch instead of master (which is default value).
Actually, there seems to be an answer to precisely this question on the Jenkins GitHub plugin page :
Trigger a build when a change is pushed to GitHub
As @thatway_3 mentioned, this is possible with a plugin. The Multi-Branch Project Plugin that they linked to is deprecated, but you can use the Pipeline Multibranch Plugin instead.
If you install that plugin and then create a new job of type "Pipeline Multibranch", you can configure that to track a particular repository. It will then (correctly!) build all branches from there.
See also: https://jenkins.io/blog/2015/12/03/pipeline-as-code-with-multibranch-workflows-in-jenkins/
Hope this helps.