Re: Auto-increment semantic version number for CD pipeline with git and docker
On Fri, Oct 27, 2017 at 1:58 AM ahardy42 wrote: > How can I tell maven to increment the version and commit the edited pom > without the CI platform seeing the commit and kicking off again in an > infinite loop? Indeed. If you just use the maven-release-plugin, as you should, on something like Gitlab CI, for example, then indeed you'll get an infinite loop. I've been burned by this several times. Some of these CI systems have a way to specify skipping CI on a given checkin. For example, in Gitlab, you can use "[skip ci]" in your commit message, and any configured pipelines won't run: https://docs.gitlab.com/ee/ci/yaml/#skipping-jobs This is true of Travis CI as well: https://docs.travis-ci.com/user/customizing-the-build/#Skipping-a-build So if you set the property either on the command line or in your pom.xml to contain "[skip ci]" (in Gitlab's or Travis CI's case), you will be good ( http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#scmCommentPrefix). The commits that the maven-release-plugin will have this string in their commit message, and that will break the infinite loop. Best, Laird -- https://about.me/lairdnelson
Re: Auto-increment semantic version number for CD pipeline with git and docker
Hi, On 26/10/17 19:31, ahardy42 wrote: The projects I'm working on are migrating towards a micro-services architecture and my aim is to find a way to implement: - auto-increment the version number see my comments later ... - semantic versioning (3.1.99, 3.1.100, 3.1.101 etc) Just a kind how you define the version in your pom file...and be aware how to change minor/major/patch... - using the maven pom version as the master or source version number - running it in maven on the CI server builds From what I read online, this is beginning to sound like alchemy. There seem to be several blockers. Can you mention some of those sources? How can I tell maven to increment the version and commit the edited pom without the CI platform seeing the commit and kicking off again in an infinite loop? I can't see any way of doing it without branching and merging/rebasing. Maybe I misunderstand a thing here but what about the usual maven-release-plugin ? This can be run on a CI server also on command line directly for a developer if it's needed (But I would recommend to do that only on CI)...BTW: Can you explain the part with the infinite loop ? I don't get that point? Just by using mvn -B release:prepare release:perform BTW: Why should a change to the code being ignored by the CI platform? [1]: http://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html My second main issue that I wonder about is: a developer commit may pass all its tests and reach the maven deploy phase, at which point the automated CI job wants to commit the updated pom with the incremented version - but it might come after a second developer commits. This also points to branching and then merging. To make things clear here. The CI could do a release procedure on it's own...(can be done by serveral pipeline steps)...But I would recommend to use the maven-release-plugin at the first place...(If you really like you can do it on your own).. The default strategy of maven-release-plugin is for the prepare goal like the following (from the docs): * Check that there are no uncommitted changes in the sources * Check that there are no SNAPSHOT dependencies * Change the version in the POMs from x-SNAPSHOT to a new version (you will be prompted for the versions to use) * Transform the SCM information in the POM to include the final destination of the tag * Run the project tests against the modified POMs to confirm everything is in working order * Commit the modified POMs * Tag the code in the SCM with a version name (this will be prompted for) * Bump the version in the POMs to a new value y-SNAPSHOT (these values will also be prompted for) * Commit the modified POMs Afterwards the release:perform will do the following: * Checkout from an SCM URL with optional tag * Run the predefined Maven goals to release the project (by default, deploy site-deploy) And yes during the above prepare part (running tests against changed pom's) there can be another commit which might fail the commit on master/trunk for the changed pom's but it's very unlikely but of course possible...after the tags has been created there is no issue on that, cause the rest of the build will be done directly on the created tag which is not influenced by commits on master/trunk... I can sympathise with all the continuous delivery / microservices / devops bloggers who have posted their articles about version numbers with ${code.branch}.${commit.date}.${build.number}.${sha1} but I can't help seeing that solution as a work-around which makes it impossible to remember what version you're on. The question is if you really use different branches...in the meantime many people have suggested to prevent use of branches cause it violates the principle of integration cause the integration is done at the time of merge which might be too lateIf you think about this you have only a single version available...and no need for different versions... Apart from that I don't see the need for a part ${build.number} and ${commit.date} ?... Maybe this can help: http://maven.apache.org/maven-ci-friendly.html Have I missed something when searching the net for the last couple of hours? The question is what exactly is your problem? I can suggest you a simple model. Just just use the master/trunk for producing releases after each change (either via merge or via direct commit; This is a different story to tell) on the master/trunk. This means that you can simply prevent parallel build of master/trunk...so in the end the master/trunk will always produce a single version. Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Auto-increment semantic version number for CD pipeline with git and docker
The projects I'm working on are migrating towards a micro-services architecture and my aim is to find a way to implement: - auto-increment the version number - semantic versioning (3.1.99, 3.1.100, 3.1.101 etc) - using the maven pom version as the master or source version number - running it in maven on the CI server builds >From what I read online, this is beginning to sound like alchemy. There seem to be several blockers. How can I tell maven to increment the version and commit the edited pom without the CI platform seeing the commit and kicking off again in an infinite loop? I can't see any way of doing it without branching and merging/rebasing. My second main issue that I wonder about is: a developer commit may pass all its tests and reach the maven deploy phase, at which point the automated CI job wants to commit the updated pom with the incremented version - but it might come after a second developer commits. This also points to branching and then merging. I can sympathise with all the continuous delivery / microservices / devops bloggers who have posted their articles about version numbers with ${code.branch}.${commit.date}.${build.number}.${sha1} but I can't help seeing that solution as a work-around which makes it impossible to remember what version you're on. Have I missed something when searching the net for the last couple of hours? -- Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org