> From: bmat...@batmat.net
> Date: Sat, 15 Feb 2014 22:07:26 +0100
> Subject: Re: Possible build collision between CI snapshot build and Release
> build
> To: users@maven.apache.org
>
> OK, so this has to be CVCS (svn and so on) specific?
> I didn't check if the release-plugin commits + push each time. If this is
> so, it should be fixed so that this cannot happen.
>
> I would say that though this is a valid technical concern, it's very
> unlikely to happen in real life.
>
> Let's take an example with a well known CI server, and specifically with
> svn:
>
> * You start a release. At the end of the release:prepare, the
> release-plugin commits the poms just before copying the path to the tags
> directory, then reverting the poms to the next snapshot development version.
MG>while release:prepare is working to output release ArtifactId-1.1-RC1
MG>then the POMs are reverted to ArtifactId=1.0-SNAPSHOT?
MG>Please clarify
> * Unfortunately, the CI kicks in just there, just after that commit, and
> before the trunk comes back to snapshot.
>with Jenkins (and Hudson), there's a default delay of some seconds,
> historically to support VCS like CVS that wouldn't commit files in an
> atomic manner
> * So, Jenkins is gonna wait those seconds before actually starting the
> build. Then it asks the VCS once more if a new change occurred. So, the
> probability to encounter this issue is even lower...
>
> So, all in all, if that's the issue you're talking about. Not sure it's
> worth to worry a lot :-).
>
> Btw, if you use a repo manager with a staging area, then at worse you're
> gonna create a staging repo from the CI build in addition to your release
> build.
MG>so in the case of Nexus the staging repo would input SNAPSHOTS from CI and
based on
MG>Staging artifacts pass each one of predefined and custom rulesets Nexus
would release them to PROD as RC
MG>release has a separate build?
MG>what would happen if the RC doesnt build..revert it and send it back to
SNAPSHOTS?
MG>please clarify
>So, in the end you won't be able to push many releases under the
> same names
MG>the artifact name changes?
MG>or is it the version changes?
MG>please clarify
>and your release should still be able to proceed.
>
> HTH
>
>
>
> 2014-02-15 16:51 GMT+01:00 Thomas Broyer <t.bro...@gmail.com>:
>
> > On Sat, Feb 15, 2014 at 4:18 PM, Baptiste Mathus <bmat...@batmat.net>
> > wrote:
> >
> > > Hi Dan,
> > > Not sure what you mean. You say "CI", are you taking about a specific
> > > server? If Jenkins for example, wouldn't it then be more a Jenkins user
> > ml
> > > question?
> > >
> > > And I don't see how a snapshot build could interfere with another build
> > > with a release version.
> > > Could you give details about your issue so that we can help you?
> > >
> >
> > mvn release:prepare does a first commit with the POM modified with the
> > no-SNAPSHOT version, then another commit with the POM modified with the
> > "next" SNAPSHOT version.
> > If a build is triggered for the first commit and basically does a "mvn
> > install" or, worse, a "mvn deploy", then it'll end up deploying your
> > release version, the very same that "mvn release:perform" will deploy too
> > (very same version information, not necessarily the same artifact: might
> > not deploy javadoc and sources for example, or the artifact might be
> > slightly different because you have plugins in a profile triggered only on,
> > or never on, release builds).
> > I think that what Dan referred to as a "CI snapshot build" is the kind of
> > build triggered by a commit (which generally builds snapshots).
> >
> >
> > >
> > > Cheers
> > > Le 15 févr. 2014 07:01, "Dan Tran" <dant...@gmail.com> a écrit :
> > >
> > > > Hello
> > > >
> > > >
> > > > It is possible that while release:prepare cutting the tag and CI for
> > > > snapshot build wakeup at the same time. Is there a way to prevent
> > this?
> > > > like a a profile to fail the build if the version happen to be a
> > release
> > > > version. Ie is there a way to detect this in a profile?
MG>profile is a snapshot of state information of the maven lifeycle at that
particular point in time
MG>some typical uses for profiles:
MG>did JVM change?
MG>did OS change?
MG>is this test only (dry run)?
MG>will we enable logging?
MG>do we need to enable security?
MG>if your artifact version is assigned to a property and property changes yes
then you can detect it and then run it thru another MG>plugin
MG>if the version is appended (as in the typical structure of a GAV) then no
maven will not detect any property change
MG>(since no property has changed)
> > > >
> > > > I currently have to keep remind my self to turn off CI snapshot build
> > > while
> > > > release is in progress,
MG>compile and release plugins should *not* be executing at same time
MG>snapshots are typically built earlier on during 'compile' phase
MG>if the snapshot build does fail you want to exit the lifecycle (and not
continue on to pre-site)
MG>release is built later during pre-site phase (as seen in this pom
illustrated below)
MG>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.4.2</version>
<executions>
<execution>
<id>execution1</id>
<phase>pre-site</phase>
....
MG>
> > > >and too many to remember.
> > > >
> > > > Advice is greatly appreciated
> > > >
> > > > -Dan
> > > >
> > >
> >
> >
> >
> > --
> > Thomas Broyer
> > /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> <
> > http://xn--nna.ma.xn--bwa-xxb.je/>
> >
>
>
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
