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 late....If 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
