I am reading https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin#GitPlugin-AdvancedFeatures which allows pre-builds of feature branches before pushing commits to the master branch, effectively implementing a pre-commit build/test queue.
It says under Using Git, Jenkins and pre-build branch merging
:
Set up your Jenkins project, and leave the 'branch' field in the Git SCM blank. This will cause Jenkins to consider any change on any branch for building.
Next, pick a particular branch name as the integration target in the 'Advanced' section - (e.g. 'master', or 'stable'), and select 'Merge before build'.
Select 'Push GIT tags back to origin repository' from the post-build actions (this is required to update your centralised git repo with the results of the build).
Now, developers should never commit directly to your integration branch (the 'master' or 'stable'). Instead, they should either use feature branches, or create new remote branches on commit (e.g : "git push origin HEAD:refs/heads/myNewFeature"). You could also set up your GIT repository to only accept commits onto the integration branch from Jenkins.
You're done. Commits should now be automatically merged with the integration branch (they will fail if they do not merge cleanly), and built. If the build succeeds, the result of the merge will be pushed back to the remote git repository.
Now I often have feature branches that I would like to continue developing on, and only merge them into master
later.
As far as I understand, this setup will merge and push any feature branch into master
as soon as it builds.
(How) Can Jenkins support my use case, building all feature branches, but merging only those into master
that I indend to be merged?
I have a build pipeline where I only want the develop branch to merge back to my stable branch. All others should not be merged. The way I've solved this is to have a separate job for the merge. When the build job is complete, the 'merge' job is only triggered if the environment variable GIT_BRANCH equals 'develop'.
Jenkins doesn't have a very good conditional trigger that works the way I want. Here is how I set up my build job to conditionally trigger the merge step.
So the process is that the trigger.properties file is first removed to make sure a previous run didn't conflict. Then, check to see if the git branch is develop. If it is, recreate the trigger.properties file. The post-build step requires that file to exist for the next job to get triggered.
Now you can perform the kinds of merging you like in a job made just for that. You can also modify this process so that more than one branch makes it to the merge job.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With