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 <rfscho...@apache.org> wrote: > Op Fri, 28 Nov 2014 00:54:29 +0100 schreef <alejandro.e...@grassvalley.com > >: > > > 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: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
