We are following trunk based development approach, where when a feature is ready, we merge it to master and create release branch with semantic version, so we have full control on major/minor/patch versioning,
eg :
release/1.0.0 .
release/1.0.1 etc ..
We run gitversion on our build step which is considering versioning provided in branch name and creating version based on it (default gitversion behavior), and we propagate to our lower systems
We tag this version only once it got successfully deployed to production (last stage in our ci/cd workflow)
The issue I am seeing right now is when cherry picking bug fixes and merging to release branch which is not tagged yet. (typical trunk based approach)
the behaviour I was looking for is as follows:
assume release/1.0.0 (current tagged release branch) ,gitversion - appname-1.0.0-rc.1 .
After a bug fix merged to master
- cherry-pick bug fix commits from master , merge to release/1.0.0
- gitversion bump patch value to appname-1.0.0-rc.2
- new commit on release/1.0.0 branch
- gitversion bump patch value to appname-1.0.0-rc.3
Instead, I am seeing the following behaviour:
- cherry-pick bug fix commits from master , merge to release/1.0.0
- gitversion doesn't increment patch value, semantic version stays at appname-1.0.0-rc.1
- new commit on release/1.0.0 branch
- semantic version stays at appname-1.0.0-rc.1
Here are the configs I m using
GitVersion.txt
GitVersion has a hierarchy it uses for determining the calculated version, all defined by the various default branch configurations, which can be seen by executing GitVersion /showConfiguration.
It seems like you need to customize your configuration based on your team's workflow and branching model in order to achieve the desired behavior.
Related
I have recently started to experiment code review using Gerrit Code Review. Now I am trying to create a pipeline in jenkins and I have some issues with building based on a specific branch.
This is what I want to obtain:
I have 2 remote branches: master and develop.
For each new feature I create a local branch and I use git push origin HEAD:refs/for/develop to send the changes to review in order to be eventually merged into the remote's develop branch.
After the changes are accepted and the merge is finalized the code from the develop branch should be built and the result will be deployed to server_1.
At some point the develop branch will be merged into the master branch. The code from the master branch will be built and the result will be deployed to server_2.
I have managed to use Patchset Created event to start the build for the changes that are being reviewed. And probably I will use Change Merged event to start the build based on the develop branch after the changes have been merged
I made the following settings:
Refspec: $GERRIT_REFSPEC:$GERRIT_REFSPEC
Branches to build: $GERRIT_REFSPEC
disabled Lightweight checkout
I tried to use the Ref Updated event to start the build when I push a commit directly into the develop from the local develop branch but it results in a failure. Why is this happening? What settings should I make to make it work?
Also how do I deploy code to the right server based on the current branch name?
Jenkins provides lengthy documentation regarding how to specify which branches it will build from. https://plugins.jenkins.io/git/
None of that though answers this specific question, or if it does, I cannot seem to achieve this.
How to specify that Jenkins will use whichever branch is normally checked out when cloning, such as the default branch specified in Github
Does this even make sense or is this even possible?
EDIT: specifically what should go in the red circle to checkout the default branch in Github
Jenkins respects the default branch over HEAD. Also, it depends how you configure you Jenkins job if it's a mulit-branch pipeline then you don't need to specify which branch it should build, by default it will scan you GitHub repo and build the changes made on branch and it will trigger the build.
If it's pipeline job then you can specify which branch it should built by editing the job configuration on Jenkins job and specifying the particular branch name in the section Branches to build
I hope this is what you are looking for.
I have a Jenkins Multi branch job that checks out and builds code from GitLab.
Until recently it was working without issue but now some (but not all) branches from the good master fail to build.
Master always builds without issue.
When I branch master either from the repo in GitLab or via a git checkout -b locally and push back to Gitlab and then allow the multibranch job to pick up the new branch it fails to build it.
I get the message from the pipeline plugin SCMBinder class: "Could not determine exact tip revision of [branch]; falling back to nondeterministic checkout".
When I do a git status in the workspace on either master or a slave the Head is detached.
When I git clone the code locally and checkout the branch everything is fine and the head is properly attached.
Additionally, when I create a simple pipeline job in Jenkins with the problem branch it builds ok and inspection of the workspace shows the head attached.
I have upgraded Jenkins and the plugins but this has not helped.
The confusing thing is that I have some other branches I created from the same master that builds perfectly fine in the same multibranch pipeline job.
Also if I branch a good branch then I get the same issue in the multibranch pipeline.
Can anyone suggest what is going wrong?
I also faced similar issue for multi branch Jenkins project.
When I clicked the option "Scan Multi branch pipeline now" in the left side menu, the problem got resolved.
Hope it might help some one.
I found the answer to this, so answering it here to help others and stop anyone from wasting their time on it.
Essentially this was caused by linux/windows interoperability issues/differences around the use of case in the branch naming which translates into a folder naming issue because windows does not care about case but GIT does.
Simply put, the first branches I previously created for the problem repo I was using a prefix lets call it "Prefix" with an uppercase "P".
These branches were pulled into a multi-branch pipe and built ok.
Then, I created a branch with the prefix "prefix" with a lower-case "p". This branch failed to build in the multi-branch pipeline.
As we know Windows does not care about case and so does not create a new folder structure in .git for "prefix" as it thinks it has one already called “Prefix”.
The appropriate HEAD and commit information is put under the original file structure under “Prefix”.
GIT however when it tries to checkout the code cannot find the head/commit information for the branch starting "prefix" as it is looking in .git for the commit/head details under "prefix" and not "Prefix" which does not exist hence results in a detached head.
I am going to start enforcing some syntax rules for branch naming in future so that this does not happen again.
I got this problem apparently because of a Jenkins upgrade. I had to (re)create the "Branch Sources" part of the configuration to fix it.
I had the same issue exactly , but with Bitbucket .
For me the issue happened due to a dev/ or Dev/ Prefix being used,
While the only prefixes defines on the Bitbucket side were :
bugfix/
feature/
hotfix/
release/
Tested the same branch with feature/ instead of dev/ worked perfectly ,
Also changing the prefix from feature/ to dev/ in bitbucket worked , but the issue there is that you cant add additional prefixed , only change one of the four already there , so i just ended up enforcing a policy to prevent people from using dev/ or any other abnormal prefixes in their branch names.
I am using the "inverse" build strategy. When we do a merge from feature branch to development branch, then from development branch to release branch. We can see Jenkins did see the changes in the branch, but started only one build. It's not starting the build for origin/REL-Sprint1606. There is line shows Label=[origin/REL-Sprint1606]
Checking out Revision b81dd73053889e753b41565a4ecec99c081eb1b0 (origin/development, origin/REL-Sprint1606)
Regular expression run condition: Expression=[.*\/[dD][eE][vV].*], Label=[origin/development ]
I found this bug report to Jenkins, but it's closed now:
Git plugin only triggers a build for one branch
https://issues.jenkins-ci.org/browse/JENKINS-11337
Is it possible to run an Automated Build when you Merge a Feature Branch into the Development Branch?
When a Developer is done working on their Feature Branch, they will Merge the Feature Branch into the Development Branch. When it is Merge, I would like to fire off an Automated Build, that will run the Unit Tests.
With Continuous Integration, you run the Build when you check in a Changeset. I want to run Continuous Integration when I Merge a Branch into another Branch.
This isn't much different than setting up a build for a normal check in. You would just set up a trigger/build definition on the appropriate branch for the approriate reason. Once the merge is performed into the branch and checked in, this would trigger the build normally.
From my source view see:
KritnerWebsite is trunk, KritnerWebsite-branch is my dev branch.
I complete development/check-ins on the branch, then when done I merge into trunk. At which point the following build definition takes over:
Notice in above the monitored folder for the trigger (in this case gated check in) is my trunk folder in source control.
Hope this helps! :)
FYI a merge isn't actually a "merge" until you check it in and it becomes a changeset. When doing a merge, it actually just gets merged locally - into your workspace. You could technically do a local build at this point, but your build definition won't take over until you actually check it in. I'm not sure why Daniel felt this isn't an answer... as it's the same thing I went through when setting up build definitions for merges - but oh well.