We tried to examine jenkins svnmerge plugin what it can do for us to minimize efforts for automatic branching from SVN. So we checked the option "Accept Integration from Subversion feature branches" and created a new branch. This runs very easy and fine but there are a few drawbacks, we could not resolve yet:
jenkins does branching from trunk. Is it also possible to create a branch from a freshly created tag?
the new branch does not contain the incremented version number in the pom.xml. Can this be done by additional configuration?
the new branch does not contain the updated scm-connection-tag (/trunk to /branches) in the pom.xml. Can this be done by additional configuration?
I use my own branching strategy with "Execute Batch/Shell" step and command line SVN.
I use my own ant script to go through the pom.xml and replace the version number via regex.
Use JobCopy Builder when using your own branching strategy, have a "template" job, and copy from it with JobCopy and modify parameters as needed.
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.
My build configuration pulls code from multiple vcs roots. As part of my build process I build an open source project from github, which unfortunately has just introduced a dependency that breaks the build on my server.
Is there any way I can change the specification of the VCS root to limit it to the commit before the dependency was introduced? I don't want to manually run a specific commit as this would force the other repository in the build back to the same point in time, which would mean I'm never building my latest code. For reasons outside of the scope of this question, I need to build all projects from source, so can't take a pre-compiled version.
Is it possible to force teamciy to always check out the same commit of a VCS root?
Most of projects are using tags to identify versions so probably you can use it.
Or if you always need only one version you can fork repo and add branch/tack on your copy
Unfortunately git refspec does not provide possibility to specify commit by hash.
I'm learning how to use the Maven Release Plugin and I have a question with the process of tagging/branching. I'm working on a project called "test" version 1.0-SNAPSHOT. I'm ready for the release. I can prepare the release and perform the release but Maven only creates a tag and I also want a branch for maintenance (bug fixes). I know that there is a possibility to branch with the Release plugin, but the branch goal doesn't create a tag also. I understand that when you want to branch, you don't want to tag. But, generally when you create a tag from the trunk (because release 1.0 in this case), you would want to branch for future maintenance.
Is there a way to configure the prepare/perform goal(s) to also branch the project before or after creating the tag?
Thanks
AFAIK no. But simply copy the /tag/test-root-1.0 to /branches/test-root-1.0. Then you need to update the versions in the pom. For this you can simply use the "mvn versions:set" goal and set the version to "1.0.1-SNAPSHOT". You are probably up to scripting these two commands in bash script if you need to make it look as one :-)
You might want to consider integrating the maven-scm-plugin into the mix. Either scm:tag or scm:branch before or after your release goals should do the trick.