Baptiste, you are totally correct. For my case, I use one staging repo per project ( long story), so there is a very small window of collision.
Thank you for this very good advice. -Dan On Sat, Feb 15, 2014 at 1:07 PM, Baptiste Mathus <bmat...@batmat.net> wrote: > 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. > * Unfortunately, the CI kicks in just there, just after that commit, and > before the trunk comes back to snapshot. > * In 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. So, in the end you won't be able to push many releases under the > same names 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? > > > > > > > > I currently have to keep remind my self to turn off CI snapshot build > > > while > > > > release is in progress, 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/> < > > http://xn--nna.ma.xn--bwa-xxb.je/> > > > > > > -- > Baptiste <Batmat> MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! >
