Is it possible to make a release from custom branch (not develop)?
I tried to use startCommit command, but Maven JGitFlow plugin has been switched to the develop branch before release is started.
Also, when I changed git configuration manually, it was automatically changed to develop.
I would like to use following steps:
release-start - create release branch
release-finish - create tag, merge to the master and develop, update pom.xml versions.
Issue found
Create a branch from tagged version
Fix issues there
Make another release from that branch
It seems that the parameter startCommit (http://jgitflow.bitbucket.org/release-start-mojo.html#startCommit) is not enough because that provokes an exception with m5.1 (https://ecosystem.atlassian.net/browse/MJF-284). Using flowInitContext seems to work though (http://jgitflow.bitbucket.org/release-start-mojo.html#flowInitContext). You just have to adjust the develop branch (source branch for release branches) to point to your custom branch.
The only thing which cannot be achieved that way, is that during release-finish a merge back to the global develop branch is done. Usually you also don't want to merge back to master (since that may provoke git merge conflicts), which need to be resolved manually.
Related
I have just hit a roadblock and would really need some insight from someone who knows the maven-release-plugin. I am trying to use the plugin for operating with my pom file, but without having it touching/committing to the main branch, but to a separate branch so that I can later on PR from there and get the review+approval required by the branch protection policy in my repos.
Context
We use github, and the company is enforcing a new branch protection policy in our main branches for security reasons mainly.
I have been using a jenkins pipeline for releasing and delivering my code which in turn, uses the maven-release-plugin for tagging the repo, and switching the version in the pom.xml, etc.
When using github's branch protection, the release plugin cannot do the usual operations, because it cannot push straight to the main branch.
My research
I found out that the plugin supports creating a branch in the process of releasing, that would be exactly what I am looking for. So, I built the environment for trying this out:
GitHub repository
Maven project
and started running some tests. The closest to being successful, was this line (version number is not important):
mvn --batch-mode release:branch '-DbranchName=release-v1.2.1' -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false
I started with the version in the pom set to the value of the version I am releasing (it is not great, but I am willing to make that commit myself). I have checked the release:prepare docs but found nothing that would help me achieving my goal.
My question
Is there any way of telling the plugin, not to make any commits to the original branch, so that it does not get rejected by the branch protection?
I always get at least a commit to the main branch like this one:
* 934af86 2020-04-27 | [maven-release-plugin] prepare branch release-v1.2.1 (HEAD -> master) [Commiter Name]
I know it's late to answer this but I just had the same issue and maybe someone else will search for this as well.
My configuration:
Jenkins
SCM Manager (Sonia)
Git master repo restricted for PRs only
What I end up doing was checking out to new branch and do the release from there. In my SCM-Manager I removed all priviledges for this branch from other users except for jenkis to protect it from being written directly.
So in jenkins project configuration I have set "Branches to build" to "*/Master". Then I added "Check out to specific local branch" in "Additional Behaviours". In branch name I have put "master_release". Your branch should be shown when you do release for the first time.
Since this was first release I will update this answer if I encounter any issues on next iteration but from my perspective it should work.
We use gradle and have our Version-Number stored in gradle.properties.
Further we use "SNAPSHOTS" to identify builds from develop.
When creating a new release we remove the SNAPSHOT Postfix in develop, create a Release Branch and increase the Version-Number to the next SNAPSHOT Version in develop.
This process prevents merge conflicts for the gradle.properties, when finishing the release branch (which merges the last changes from release to develop branch).
But now we have the problem, that we have merge-conflicts (or worse fast-forward merges!) when creating hotfix-branches from master and merging them to open release branches and develop.
The same problem occurs with Maven Projects, where the Version-Number is located in the pom.xml.
Is there another good solution to prevent this problem? I was thinking about externalising the version-number and passing it e.g. via Build Parameter or store it in a file which is not under version control but this has the disadvantage, that you can't identify the version from the source.
Any help would be appreciate.
UPDATE
Another Idea is it, to use the Branch- / Tagname to identify the Release-Number.
I'm using TeamCity 2017.1.4 along with GitVersion.
The teamcity project itself consists of many build configurations the first of which is to run GitVersion and then all subsequent steps take a snapshot dependency on this step and pull the version from its parameters.
In most scenarios this works great, however if we create a new branch eg. /release-foo and push this, teamcity will not trigger a build because its already previously built the commit sha, unfortunately we need it to trigger again as even though the commit hasn't changed being in a new branch means it will get a different GitVersion number.
I've tried forcing the snapshot dependencies on the GitVersion build configuration to always be rebuilt but this seems kind of ugly as kind of breaks all other scenarios where this isn't a problem. I also know I could manually trigger the build telling it to rebuild all dependencies and it would work, however I'm curious if there's a nicer way to get teamcity to automatically trigger a build for a commit on a branch if that branch didn't previously exist, or indeed any other way I could approach this.
You could try configuring TeamCity to include different/more GitVersion version variables in the build, including the branch name and possibly version tags. This would provide a way for your build process to differentiate between the same commit on different branches.
See steps 1-5 of this CD post, as well as this detailed blog post on using GitVersionTask for some examples on how to use the additional info in TeamCity.
You can achieve this by triggering the build from a git hook.
As explained here, you can use a the update hook to identify pushed branches (even when several are pushed in a single operation) and for each branch (assuming it passes your triggering rules) trigger a TeamCity build using the REST API.
If you simply amend the commit on the new branch without modifying anything, it will get a new hash because of timestamp changes. I wouldn't consider this a nice solution, but imho it's better than triggering manually.
I am having a bit of trouble with the Branch Updater feature of Bamboo.
If a new commit is pushed on a branch that is using the branch updater, Bamboo checks if there are new commits on the dependent branch(in my case the master branch) and if this is the case it merges the changes and runs the build.
However, if this build fails, it is hard to recognize, if the new code on the branch itself is broken or if it just could not be merged correctly with the master. Therefore I would like that in these cases the branch is build independently first and only if this build is successful, the changes on the master are merged in and the branch is build again.
Is this possible using the branch updater feature?
A workaround might be to use multiple build plans and use one to build all branches isolated and another plan to integrate everything using the branch updater.
The "Branch Updater" feature is to merge the code from master branch into feature branch after a successful build of the master branch.
However, currently there is NO straight forward option in Bamboo (except the workaround mentioned in your OP) to build the branch and auto merge only if the branch build is successful.
Typically, the developer runs the build in local and commit the changes to repository if the local build is successful. There are two things that can go wrong.
1) While running the local build, the latest code from feature branch is not available in local. Some of the repos like GIT would complain if the local doesn't match with HEAD revision, you need to update to HEAD before you commit the changes. In this case, you can run the build again to ensure there is no problem.
2) When the master code merges with feature branch, something could go wrong
I understand that still there is a gap which can be addressed to resolve the point 2.
You can create a ticket in Bamboo with detailed explanation of the use case to add this feature.
I am trying to create Jenkins job that performs release on my project using maven-release-plugin. First step of Jenkins job is checkout from CVS by tag x-x-x. The problem is that when maven-release-plugin changes version in pom.xml and tries to commit file to CVS, commit fails (not tagging) because tag that was used during checkout is not branch tag:
cvs commit: sticky tag `x-x-x' for file `pom.xml' is not a branch
I would like to avoid creating branch tag for pom.xml just to satisfy maven-release-plugin. Is there another way?
I have been sitting with this issue myself lately and it from what I can gather there is no way to release directly from a TAG. The reason being as you mention above.
Maybe a possible approach (still untested), could be to create a branch from your tag, setting your url to the newly created branch, releasing from branch.
Anyone who has the same scenario would be greatly appreciated.