Re: Special parameters - sha1

[Bernd Eckenfels]

Hello,

If you have a POM with dependencies to other modules which are built on each 
change, you typically want to make sure you use those updated dependencies when 
you compile your projects.

With regularly changing version numbers and without using SNAPSHOT dependencies 
you will need to find a solution for this. You could use version ranges, but 
then you are not much different then using SNAPSHOT builds. This is one of the 
main reasons why we are doing manual releases - and managing the dependency 
versions by hand.

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Eric Benzacar 
Sent: Thursday, November 16, 2017 5:05:45 AM
To: Maven Users List
Cc: i...@soebes.de
Subject: Re: Special  parameters - sha1

I'm not sure what you mean when you say:

"How are you planning to deal with the changed version numbers of
dependencies?"

At which stage are you referring to?  Which dependencies with changed
version numbers?

Thanks,

Eric

On Wed, Nov 15, 2017 at 1:11 AM, Bernd Eckenfels 
wrote:

> You have to remember that POMs are also the model to describe artifacts,
> that why you should stay clear of profiles (especially if the influence
> artifact coordinates).
>
> Personally I have good experience with actually releasing things, but if
> you want to keep the build identifier, then I would agree, that handling
> this in the build job is probably the best. You can have even two
> Parameterized jobs.
>
> How are you planning to deal with the changed version numbers of
> dependencies?
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: Eric B 
> Sent: Wednesday, November 15, 2017 4:30:06 AM
> To: i...@soebes.de; Maven Users List
> Subject: Re: Special  parameters - sha1
>
> Hi,
>
> Thanks for the additional insight.  I think I understand better now how
> this works.   I'll try to explain my use case, and perhaps someone can
> provide some ideas for best practices.
>
> I started a pom refactoring because I wanted to add the enforcer-plugin for
> a release candidate to ensure there are no SNAPSHOTs in the pom.  For our
> dev purposes, we have defined that anything in a release/ branch (Gitflow)
> is a release candidate.  Anything in the dev/ branch can be a SNAPSHOT.
> Additionally, we use semantic versioning, so our versions read 4.7.0,
> 4.7.1, 5.0.0, 5.1.0, etc...  Consequently, each build coming from a release
> branch needs to have a unique version.  I don't want to update the version
> number for each build, so each build has to have a build number or sha1
> attached to the version.
>
> My build pipeline is very basic for the moment; it's a simple Jenkins
> freestyle job (not a pipeline job yet).  Ideally, I'm trying to keep it as
> simple as possible and always pass the same parameters to the maven build
> process (to make it easier for others to understand).
>
> I'm passing the following parameters to the maven build:
>  -DbranchType=release
>  -DbuildNumber=
>
> maven.config:
> -Drevision=5.0.0
>
>
>
> My thought process is I could do the following - for the normal use case
> (ie: dev branch):
> ${revision}${changelist}
> 
>   -SNAPSHOT
> 
>
>
> For a release:
> 
>   relelase
>   
> 
>branchType
>release
> 
>   
>
>   
>   ${buildNumber}
>
> 
> 
>
>
> But now I see that won't work.  So I need to pass the buildnumber on the
> command line as a SHA1 parameter.  But if I do that in this design, the
> SNAPSHOT will also include the SHA1 which is not what I want.
>
> So from what I can see, the only option is to modify the parameters on the
> command line.  Which means I have to add some additional logic to my
> Jenkins build.  This would be much easier if I had a Pipeline build but I
> don't at the moment.  I was just looking to put the intelligence in the pom
> so that anyone could easily read & understand it.
>
> Any suggestions or recommendations would be greatly appreciated.  Is there
> anyway to do this in the pom itself?
>
> Thanks,
>
> Eric
>
> On Tue, Nov 14, 2017 at 8:42 AM, Karl Heinz Marbaise 
> wrote:
>
> > Hi,
> >
> >
> > I will give some more details cause I have created the docs /
> > implementation and you mentioned my blog ;-)..
> >
> >
> > On 14/11/17 03:12, Eric B wrote:
> >
> >> Following a long thread on this list, and a blog by khmarbaise (
> >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> >> t-a-version-in-it/),
> >> I'm still a little confused as to exactly what is allowed in the special
> >> version tags for a maven pom.
> >>
> >> I know and realize that the 3 allowable tags are:
> >>   - ${revision}
> >>   - ${sha1}
> >>   - ${changelist}
> >>
> >> However, from the thread and the blog, it seems that these properties
> >> cannot be dependent on any other properties.
> >>
> >
> > Correct.
> >
> >>
> >> For example, this is fine:
> >> ${revision}-${sha1}
> >> 

Re: Special parameters - sha1

[Eric Benzacar]

I'm not sure what you mean when you say:

"How are you planning to deal with the changed version numbers of
dependencies?"

At which stage are you referring to?  Which dependencies with changed
version numbers?

Thanks,

Eric

On Wed, Nov 15, 2017 at 1:11 AM, Bernd Eckenfels 
wrote:

> You have to remember that POMs are also the model to describe artifacts,
> that why you should stay clear of profiles (especially if the influence
> artifact coordinates).
>
> Personally I have good experience with actually releasing things, but if
> you want to keep the build identifier, then I would agree, that handling
> this in the build job is probably the best. You can have even two
> Parameterized jobs.
>
> How are you planning to deal with the changed version numbers of
> dependencies?
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: Eric B 
> Sent: Wednesday, November 15, 2017 4:30:06 AM
> To: i...@soebes.de; Maven Users List
> Subject: Re: Special  parameters - sha1
>
> Hi,
>
> Thanks for the additional insight.  I think I understand better now how
> this works.   I'll try to explain my use case, and perhaps someone can
> provide some ideas for best practices.
>
> I started a pom refactoring because I wanted to add the enforcer-plugin for
> a release candidate to ensure there are no SNAPSHOTs in the pom.  For our
> dev purposes, we have defined that anything in a release/ branch (Gitflow)
> is a release candidate.  Anything in the dev/ branch can be a SNAPSHOT.
> Additionally, we use semantic versioning, so our versions read 4.7.0,
> 4.7.1, 5.0.0, 5.1.0, etc...  Consequently, each build coming from a release
> branch needs to have a unique version.  I don't want to update the version
> number for each build, so each build has to have a build number or sha1
> attached to the version.
>
> My build pipeline is very basic for the moment; it's a simple Jenkins
> freestyle job (not a pipeline job yet).  Ideally, I'm trying to keep it as
> simple as possible and always pass the same parameters to the maven build
> process (to make it easier for others to understand).
>
> I'm passing the following parameters to the maven build:
>  -DbranchType=release
>  -DbuildNumber=
>
> maven.config:
> -Drevision=5.0.0
>
>
>
> My thought process is I could do the following - for the normal use case
> (ie: dev branch):
> ${revision}${changelist}
> 
>   -SNAPSHOT
> 
>
>
> For a release:
> 
>   relelase
>   
> 
>branchType
>release
> 
>   
>
>   
>   ${buildNumber}
>
> 
> 
>
>
> But now I see that won't work.  So I need to pass the buildnumber on the
> command line as a SHA1 parameter.  But if I do that in this design, the
> SNAPSHOT will also include the SHA1 which is not what I want.
>
> So from what I can see, the only option is to modify the parameters on the
> command line.  Which means I have to add some additional logic to my
> Jenkins build.  This would be much easier if I had a Pipeline build but I
> don't at the moment.  I was just looking to put the intelligence in the pom
> so that anyone could easily read & understand it.
>
> Any suggestions or recommendations would be greatly appreciated.  Is there
> anyway to do this in the pom itself?
>
> Thanks,
>
> Eric
>
> On Tue, Nov 14, 2017 at 8:42 AM, Karl Heinz Marbaise 
> wrote:
>
> > Hi,
> >
> >
> > I will give some more details cause I have created the docs /
> > implementation and you mentioned my blog ;-)..
> >
> >
> > On 14/11/17 03:12, Eric B wrote:
> >
> >> Following a long thread on this list, and a blog by khmarbaise (
> >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> >> t-a-version-in-it/),
> >> I'm still a little confused as to exactly what is allowed in the special
> >> version tags for a maven pom.
> >>
> >> I know and realize that the 3 allowable tags are:
> >>   - ${revision}
> >>   - ${sha1}
> >>   - ${changelist}
> >>
> >> However, from the thread and the blog, it seems that these properties
> >> cannot be dependent on any other properties.
> >>
> >
> > Correct.
> >
> >>
> >> For example, this is fine:
> >> ${revision}-${sha1}
> >> where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e
> >>
> >>
> >> However, based on the further docs at
> >> https://maven.apache.org/maven-ci-friendly.html, this design would
> fail:
> >>
> >
> > which is not mentioned in the docs...
> >
> >
> >> ${revision}-${sha1}
> >>
> >> 
> >>   ${buildNumber}
> >> 
> >>
> >>
> >> and call it as -Drevision=1.2.3 -DbuildNumber=9
> >>
> >
> > The problem is simply that buildNumber is not correctly overwritten from
> > command and not correctly handled duing the model reading / interpolation
> > at the correct time within Maven Core at the moment...
> >
> > At the moment this is only implemented for those special three
> > properties...which already has performance impacts...which is also a
> reason
> > not 

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
>