But the problem has nothing to do with Jenkins You can manually type mvn release:prepare release:perform -DdryRun=true and it will pass and then dryRun=false and it will fail
My point is about the default behaviour of a dry run not being realistic compared to a full release, which will make you miss problems that WILL fail the real release. And to make matters worse, if a real release fails, it leaves the repo in disarray. IMO it should really clean up to the same state as it was when the release was started. If this is not possible because you cannot easily revert changes in a SCM (or in other words, you cannot do the WHOLE release as a transaction) then at least there should be a realistic, non-persistent check for those operations that will give you a high degree of certainty that a real release will succeed. That's what a dry run is supposed to do. It will never be 100% sure (example, what if while deploying the release artifact the internet connection drops. This can't be checked by a successful dryRun) but it should be as real as possible, and right now the dryRun is so much simpler than the real release that it becomes meaningless. There are so many steps in a release (which is what makes this plugin so necessary) that there's many opportunities for failures: unstable dependencies, unstable parents, artifacts not being SNAPSHOTs, missing SCM tags (which are needed everywhere since SCM inheritance doesn't work well with git), errors in javadoc (that only since recently started failing the build), no write access in SCM repo, tag already existing in SCM repo, artifacts already existing in remote maven repo (i.e. accidental redeploys). All these I have actually encountered in real life in an enterprise setting. And i'm not saying all these are not detected by a default dryRun, some of them are. I just wanted to make the point that releasing has many potential failure points Alejandro Endo | Software Designer/Concepteur de logiciels From: Stephen Connolly <[email protected]> To: Maven Users List <[email protected]>, Date: 2014-11-28 12:52 PM Subject: Re: release plugin issue Ohhhh wait a sec.... you're using the evil job type... http://javaadventure.blogspot.ie/2013/11/jenkins-maven-job-type-considered-evil.html Well all bets are off then.... that will most likely royally screw you over On 28 November 2014 at 17:45, Robert Scholte <[email protected]> wrote: > Op Fri, 28 Nov 2014 00:54:29 +0100 schreef <[email protected] > >: > > > I'm using the release-plugin v2.5.1 and I'm often encountering two >> recurring stories with failed releases >> >> 1) Now the release can fail due to errors in the javadoc. This is not a >> problem, the problem is that IF there are problems in the javadoc the >> release doesn't complete but the two commits and the tag has been done so >> after fixing the javadoc I need to reset the git repo to right before the >> failed released AND I have to remove the tag to try again. I am releasing >> from jenkins so the resume flag is set to false. if something fails we >> start from the beginning, which makes sense in a build server IMO. My >> suggestion here would be to generate all those artifacts (javadoc and >> source) before committing and tagging the code, that way if they fail, the >> repo is not in an invalid state. Another option would be improvement #2 >> >> 2) Very often the dryRun succeeds but the real release fails, to the point >> where the dryRun is meaningless. This defeats the whole purpose of a >> dry-run. The problem is that the dry run is over simplified. For example, >> again, if there are javadoc problems they won't be spotted because the >> dry-run doesn't run javadoc generation. Anything that's part of the real >> build should be run on the dry-run except for things that make persistent >> changes. Another problem I encounter often is that the real release fails >> because the tag already exists in SCM (leftover from a previous failed >> release). This should also be validated by the dryRun. If a real release >> can fail because a tag is already present then the dry run should fail if >> the tag is already present >> >> What do you guys think? If these points are considered valid I will open a >> ticket at least for the second one, which is the worse of the two >> >> > It's also possible to do a dryrun for the release:perform since version > 2.3 [1] > That's still not the default of the jenkins m2-release-plugin, but it > works. > > Robert > > [1] https://jira.codehaus.org/browse/MRELEASE-736 > > >> Alejandro Endo | Software Designer/Concepteur de logiciels >> >> >> DISCLAIMER: >> Privileged and/or Confidential information may be contained in this >> message. If you are not the addressee of this message, you may not >> copy, use or deliver this message to anyone. In such event, you >> should destroy the message and kindly notify the sender by reply >> e-mail. It is understood that opinions or conclusions that do not >> relate to the official business of the company are neither given >> nor endorsed by the company. >> Thank You. >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
