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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Karl Heinz Marbaise-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

ljnelson
In reply to this post by ahardy42
On Fri, Oct 27, 2017 at 1:58 AM ahardy42 <[hidden email]>
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 <scmCommentPrefix> 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
Reply | Threaded
Open this post in threaded view
|

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

stephenconnolly
On Fri 27 Oct 2017 at 23:28, Laird Nelson <[hidden email]> wrote:

> On Fri, Oct 27, 2017 at 1:58 AM ahardy42 <[hidden email]>
> 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 <scmCommentPrefix> 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
Reply | Threaded
Open this post in threaded view
|

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

stephenconnolly
On Sun 5 Nov 2017 at 11:31, Stephen Connolly <
[hidden email]> wrote:

>
> On Fri 27 Oct 2017 at 23:28, Laird Nelson <[hidden email]> wrote:
>
>> On Fri, Oct 27, 2017 at 1:58 AM ahardy42 <[hidden email]>
>> 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 <scmCommentPrefix> 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
Reply | Threaded
Open this post in threaded view
|

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

Arnaud bourree-2
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 <[hidden email]
>:

> On Sun 5 Nov 2017 at 11:31, Stephen Connolly <
> [hidden email]> wrote:
>
> >
> > On Fri 27 Oct 2017 at 23:28, Laird Nelson <[hidden email]> wrote:
> >
> >> On Fri, Oct 27, 2017 at 1:58 AM ahardy42 <[hidden email]
> >
> >> 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 <scmCommentPrefix> 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
>
Reply | Threaded
Open this post in threaded view
|

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

ahardy42
In reply to this post by ljnelson
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

stephenconnolly
In reply to this post by Arnaud bourree-2
On Wed 15 Nov 2017 at 18:11, Arnaud bourree <[hidden email]>
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 <
> [hidden email]
> >:
>
> > On Sun 5 Nov 2017 at 11:31, Stephen Connolly <
> > [hidden email]> wrote:
> >
> > >
> > > On Fri 27 Oct 2017 at 23:28, Laird Nelson <[hidden email]> wrote:
> > >
> > >> On Fri, Oct 27, 2017 at 1:58 AM ahardy42 <
> [hidden email]
> > >
> > >> 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 <scmCommentPrefix> 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
Reply | Threaded
Open this post in threaded view
|

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

ahardy42
In reply to this post by stephenconnolly
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

ahardy42
In reply to this post by stephenconnolly
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

stephenconnolly
In reply to this post by ahardy42
On Thu 16 Nov 2017 at 13:26, ahardy42 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

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

ahardy42
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

stephenconnolly
On Thu 16 Nov 2017 at 21:10, Adam Hardy <[hidden email]>
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

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

ahardy42
On Thursday, November 16, 2017 23:10 GMT, Stephen Connolly <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]