On Wed 15 Nov 2017 at 18:11, Arnaud bourree <arnaud.bour...@gmail.com> 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 <ljnel...@gmail.com> 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 <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
