Re: Auto-increment semantic version number for CD pipeline with git and docker

[Adam Hardy]

On Thursday, November 16, 2017 23:10 GMT, Stephen Connolly 
 wrote:
> Only use release versions for releases
>
> For any builds in between releases, always use a SNAPSHOT. If you don’t
> want to commit to a version (which it sounds like you don’t) then pick
> either SNAPSHOT or major-SNAPSHOT (eg 1-SNAPSHOT) and *keep* the master
> branch *always* on that version, irrespective of what versions get released.
>
> Maven treats release version numbers differently from SNAPSHOT... it sounds
> like you want to ignore the distinction... that will cause issues for your
> developers... if you want to learn those issues the hard way, do what you
> want... if you want to take the advice of a veteran, you will use a
> SNAPSHOT for the master branch.

Hmm, I think we're talking at cross-purposes. I do not intend to do what you 
are worried about. The main reason I am looking at this is to try to get the 
microservices architecture style release numbers used by my team back to the 
straight and narrow "semantic versioning". At the moment the maven pom version 
is not used at all. The team relies solely on git commit ids and docker tags. 
I'd like to improve upon that.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Auto-increment semantic version number for CD pipeline with git and docker

[Stephen Connolly]

On Thu 16 Nov 2017 at 21:10, Adam Hardy 
wrote:

> On 16/11/17 20:40, Stephen Connolly wrote:
> > I think you’ll want to keep master with a version of at least SNAPSHOT or
> > 1-SNAPSHOT and wholesale replace it with the real build version number on
> > the CI server and just have that version in the tag.
> >
> > The issue with using release versions on master is that developers will
> get
> > inconsistencies in builds because release versions are assumed final and
> > will never be refetched.
> >
> > Ignore this advice at your peril
>
> I don't understand what you are warning me about.


Only use release versions for releases

For any builds in between releases, always use a SNAPSHOT. If you don’t
want to commit to a version (which it sounds like you don’t) then pick
either SNAPSHOT or major-SNAPSHOT (eg 1-SNAPSHOT) and *keep* the master
branch *always* on that version, irrespective of what versions get released.

Maven treats release version numbers differently from SNAPSHOT... it sounds
like you want to ignore the distinction... that will cause issues for your
developers... if you want to learn those issues the hard way, do what you
want... if you want to take the advice of a veteran, you will use a
SNAPSHOT for the master branch.

>
>
> The release process I am trying to automate is utterly simple. The
> developer:
>
> - codes and tests everything
> - increments the version number
> - pushes to master
> - tags the push
>
> If at some later date we want to go back to a certain version, we check
> out that
> tag.
>
> Admittedly there may be complexities to deal with, but the approach is to
> keep
> it simple.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
> --
Sent from my phone

Re: Auto-increment semantic version number for CD pipeline with git and docker

[Adam Hardy]

On 16/11/17 20:40, Stephen Connolly wrote:

I think you’ll want to keep master with a version of at least SNAPSHOT or
1-SNAPSHOT and wholesale replace it with the real build version number on
the CI server and just have that version in the tag.

The issue with using release versions on master is that developers will get
inconsistencies in builds because release versions are assumed final and
will never be refetched.

Ignore this advice at your peril


I don't understand what you are warning me about.

The release process I am trying to automate is utterly simple. The developer:

- codes and tests everything
- increments the version number
- pushes to master
- tags the push

If at some later date we want to go back to a certain version, we check out that 
tag.


Admittedly there may be complexities to deal with, but the approach is to keep 
it simple.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Auto-increment semantic version number for CD pipeline with git and docker

[Stephen Connolly]

On Thu 16 Nov 2017 at 13:26, ahardy42  wrote:

> V. interesting, thanks.
>
> I'm using TeamCity so controlling an infinite loop using trigger configs
> should be easy.
>
> However I don't want to use snapshot versioning at all, so the
> maven-release-plugin is essentially not the right tool for the job.
>
> These projects are microservices so every code commit is a release
> candidate. My goal is to get maven to increment the build number on each
> build - the build number shouldn't be switched back and forth between
> -SNAPSHOT and non-snapshot.
>
> The CI server should run the tests and verify that they pass and if so,
> merge or rebase the checkin into the master.
>
> That blog post by Stephen hits it square between the eyes - although in my
> case to get rid of -SNAPSHOT non-versions, I'll probably need to write a
> plugin to run the git plugin through the required steps.


I think you’ll want to keep master with a version of at least SNAPSHOT or
1-SNAPSHOT and wholesale replace it with the real build version number on
the CI server and just have that version in the tag.

The issue with using release versions on master is that developers will get
inconsistencies in builds because release versions are assumed final and
will never be refetched.

Ignore this advice at your peril


>
> Surprised it doesn't exist already. Probably does, but just not widely
> publicised.
>
> Apologies for the long pause before answering! Too much firefighting.
>
>
>
>
> --
> 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
>
> --
Sent from my phone

Re: Auto-increment semantic version number for CD pipeline with git and docker

[ahardy42]

V. interesting, thanks. 

I'm using TeamCity so controlling an infinite loop using trigger configs
should be easy.

However I don't want to use snapshot versioning at all, so the
maven-release-plugin is essentially not the right tool for the job. 

These projects are microservices so every code commit is a release
candidate. My goal is to get maven to increment the build number on each
build - the build number shouldn't be switched back and forth between
-SNAPSHOT and non-snapshot.

The CI server should run the tests and verify that they pass and if so,
merge or rebase the checkin into the master.

That blog post by Stephen hits it square between the eyes - although in my
case to get rid of -SNAPSHOT non-versions, I'll probably need to write a
plugin to run the git plugin through the required steps. 

Surprised it doesn't exist already. Probably does, but just not widely
publicised.

Apologies for the long pause before answering! Too much firefighting.




--
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

Re: Auto-increment semantic version number for CD pipeline with git and docker

[ahardy42]

V. interesting, thanks. 

I'm using TeamCity so controlling an infinite loop using trigger configs
should be easy.

However I don't want to use snapshot versioning at all, so the
maven-release-plugin is essentially not the right tool for the job. 

These projects are microservices so every code commit is a release
candidate. My goal is to get maven to increment the build number on each
build - the build number shouldn't be switched back and forth between
-SNAPSHOT and non-snapshot. The main aim is to keep it simple, v2.1.3 ->
v.2.1.4 -> v2.1.5 etc so dealing with -SNAPSHOT gets in the way.

The CI server will run the tests and verify that they pass and if so, merge
or rebase the checkin into the master somehow via maven.

That blog post by Stephen hits it square between the eyes - although in my
case to get rid of -SNAPSHOT, I'll probably need to write a plugin to run
the git plugin through the required steps. 

Surprised it doesn't exist already, IMHO semantic versioning is clearly more
desirable than the git commit hash. A maven plugin probably does, but is
just not widely publicised. 

Sorry for the long pause before answering. 




--
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

Re: Auto-increment semantic version number for CD pipeline with git and docker

[ahardy42]

I'm using TeamCity so controlling an infinite loop using trigger configs
should be easy.

I don't want to use snapshot versioning at all. 

These projects are microservices so every code commit is a release
candidate. My goal is to get maven to increment the build number on each
build - the build number shouldn't be switched back and forth between
-SNAPSHOT and non-snapshot. 

The CI server should run the tests and verify that they pass and if so,
merge or rebase the checkin into the master. 

Apologies for the long pause before answering! Too much firefighting. 






--
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

Re: Auto-increment semantic version number for CD pipeline with git and docker

[Stephen Connolly]

On Wed 15 Nov 2017 at 18:11, Arnaud bourree 
wrote:

> Hi,
>
> I like your blog post, but I need some clarification.
>
> On line 19, your pipeline snippet calls maven without goals !
> 1/ Does it means: release:prepare goal?


The line is very long, scroll horizontally and you will see line 19 on the
blog post is release:prepare release:perform


> 2/ In your idea, do we add our project maven build lines before line 22? I
> order to take decision after some automatic tests validation.


You can do whatever you want.

>
>
> On line 27, we push updated pom.
> 3/ I suppose that we deploy generated artifacts after
>

Well it depends.

The *key* point I am trying to make is that you don’t push the version bump
back to master.

When I have implemented this kind of scheme I have typically had Nexus pro
and staging support so I either drop or promote the staging repo depending
on whether I drop or push the tag.

That fits much better with a CD flow

The other key point is that the release plugin is a framework, if you have
other requirements from those that drove the Maven-release-plugin then use
the framework to build your own process...

Too many people claim Maven doesn’t fit for CD just because they don’t
understand that the release plugin was designed for a workflow that has its
own needs shaped by the release processes of Apache Foundation...

>
> Regards,
>
> Arnaud.
>
>
> 2017-11-08 22:21 GMT+01:00 Stephen Connolly <
> stephen.alan.conno...@gmail.com
> >:
>
> > On Sun 5 Nov 2017 at 11:31, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > >
> > > On Fri 27 Oct 2017 at 23:28, Laird Nelson  wrote:
> > >
> > >> On Fri, Oct 27, 2017 at 1:58 AM ahardy42 <
> adam.ha...@cyberspaceroad.com
> > >
> > >> 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.
> > >
> > >
> > > I suggest that for CD you use a slightly different pattern
> > >
> > > Do not tag the deployment branch, rather tag off-branch
> > >
> > > (Approx) Commands are probably easier to see
> > >
> > > $ git fetch origin
> > > $ git checkout master
> > > $ git reset —hard origin/master
> > > $ git clean -f
> > > $ mvn -DpushChanges=false release:prepare -B
> > > -DreleaseVersion=$RELEASE_VERSION
> > > $ git push —tags
> > > $ mvn -B release:perform
> > > $ git reset —hard origin/master
> > >
> > > The key bit here is that we do not publish the pom changes *on the
> branch
> > > being released* (-DpushChanges=false) but we publish the tags to
> provide
> > > the traceability of what is released
> > >
> > > This means that the developer does not have pom merge conflicts and
> does
> > > not see commit noise... but at the same time we have complete
> > traceability
> > > of releases
> > >
> > > The version in the pom in master branch would probably be
> 1.x.x-SNAPSHOT
> > > or x-SNAPSHOT *always* and you’d need to not deploy SNAPSHOTs to
> > > repositories used by users
> > >
> > > The hard part here is determining what to set the $RELEASE_VERSION
> > > environment variable to.
> > >
> > > This also has the advantage that the CI server will not have to try and
> > > ignore commits.
> > >
> >
> > Here is an early blog post I wrote on this topic
> >
> > https://t.co/Kuat0Dejut
> >
> >
> > >
> > >>
> > >> 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
> > >>
> > > --
> > > Sent from my phone
> > >
> > --
> > Sent from my phone
> >
>
-- 
Sent from my phone

Re: Auto-increment semantic version number for CD pipeline with git and docker

[Arnaud bourree]

Hi,

I like your blog post, but I need some clarification.

On line 19, your pipeline snippet calls maven without goals !
1/ Does it means: release:prepare goal?
2/ In your idea, do we add our project maven build lines before line 22? I
order to take decision after some automatic tests validation.

On line 27, we push updated pom.
3/ I suppose that we deploy generated artifacts after

Regards,

Arnaud.


2017-11-08 22:21 GMT+01:00 Stephen Connolly :

> On Sun 5 Nov 2017 at 11:31, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> >
> > On Fri 27 Oct 2017 at 23:28, Laird Nelson  wrote:
> >
> >> 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.
> >
> >
> > I suggest that for CD you use a slightly different pattern
> >
> > Do not tag the deployment branch, rather tag off-branch
> >
> > (Approx) Commands are probably easier to see
> >
> > $ git fetch origin
> > $ git checkout master
> > $ git reset —hard origin/master
> > $ git clean -f
> > $ mvn -DpushChanges=false release:prepare -B
> > -DreleaseVersion=$RELEASE_VERSION
> > $ git push —tags
> > $ mvn -B release:perform
> > $ git reset —hard origin/master
> >
> > The key bit here is that we do not publish the pom changes *on the branch
> > being released* (-DpushChanges=false) but we publish the tags to provide
> > the traceability of what is released
> >
> > This means that the developer does not have pom merge conflicts and does
> > not see commit noise... but at the same time we have complete
> traceability
> > of releases
> >
> > The version in the pom in master branch would probably be 1.x.x-SNAPSHOT
> > or x-SNAPSHOT *always* and you’d need to not deploy SNAPSHOTs to
> > repositories used by users
> >
> > The hard part here is determining what to set the $RELEASE_VERSION
> > environment variable to.
> >
> > This also has the advantage that the CI server will not have to try and
> > ignore commits.
> >
>
> Here is an early blog post I wrote on this topic
>
> https://t.co/Kuat0Dejut
>
>
> >
> >>
> >> 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
> >>
> > --
> > Sent from my phone
> >
> --
> Sent from my phone
>

Re: Auto-increment semantic version number for CD pipeline with git and docker

[Stephen Connolly]

On Sun 5 Nov 2017 at 11:31, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

>
> On Fri 27 Oct 2017 at 23:28, Laird Nelson  wrote:
>
>> 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.
>
>
> I suggest that for CD you use a slightly different pattern
>
> Do not tag the deployment branch, rather tag off-branch
>
> (Approx) Commands are probably easier to see
>
> $ git fetch origin
> $ git checkout master
> $ git reset —hard origin/master
> $ git clean -f
> $ mvn -DpushChanges=false release:prepare -B
> -DreleaseVersion=$RELEASE_VERSION
> $ git push —tags
> $ mvn -B release:perform
> $ git reset —hard origin/master
>
> The key bit here is that we do not publish the pom changes *on the branch
> being released* (-DpushChanges=false) but we publish the tags to provide
> the traceability of what is released
>
> This means that the developer does not have pom merge conflicts and does
> not see commit noise... but at the same time we have complete traceability
> of releases
>
> The version in the pom in master branch would probably be 1.x.x-SNAPSHOT
> or x-SNAPSHOT *always* and you’d need to not deploy SNAPSHOTs to
> repositories used by users
>
> The hard part here is determining what to set the $RELEASE_VERSION
> environment variable to.
>
> This also has the advantage that the CI server will not have to try and
> ignore commits.
>

Here is an early blog post I wrote on this topic

https://t.co/Kuat0Dejut


>
>>
>> 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
>>
> --
> Sent from my phone
>
-- 
Sent from my phone

Re: Auto-increment semantic version number for CD pipeline with git and docker

[Stephen Connolly]

On Fri 27 Oct 2017 at 23:28, Laird Nelson  wrote:

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


I suggest that for CD you use a slightly different pattern

Do not tag the deployment branch, rather tag off-branch

(Approx) Commands are probably easier to see

$ git fetch origin
$ git checkout master
$ git reset —hard origin/master
$ git clean -f
$ mvn -DpushChanges=false release:prepare -B
-DreleaseVersion=$RELEASE_VERSION
$ git push —tags
$ mvn -B release:perform
$ git reset —hard origin/master

The key bit here is that we do not publish the pom changes *on the branch
being released* (-DpushChanges=false) but we publish the tags to provide
the traceability of what is released

This means that the developer does not have pom merge conflicts and does
not see commit noise... but at the same time we have complete traceability
of releases

The version in the pom in master branch would probably be 1.x.x-SNAPSHOT or
x-SNAPSHOT *always* and you’d need to not deploy SNAPSHOTs to repositories
used by users

The hard part here is determining what to set the $RELEASE_VERSION
environment variable to.

This also has the advantage that the CI server will not have to try and
ignore commits.


>
> 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
>
-- 
Sent from my phone

Re: Auto-increment semantic version number for CD pipeline with git and docker

[Laird Nelson]

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

[Karl Heinz Marbaise]

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

[ahardy42]

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