On Sunday, November 30, 2014, Mirko Friedenhagen <[email protected]> wrote:
> Stephen, > > thanks for these hints, I sometimes used -DperformRelease=true validate as > prepGoal and as git does not force you to push tags and is able to clone > from the local repository as well, your way is much safer. However with svn > removing/readding/recommitting etc. is painful and always leads to > problems. Mirko, You've been around long enough that I guess you have internalised the trade-offs. I just wanted to explain FTR what trade-offs there are so that anyone else finding this thread has the awareness - Stephen > > Regards > Mirko > -- > Sent from my mobile > On Nov 30, 2014 12:40 AM, "Stephen Connolly" < > [email protected] <javascript:;>> wrote: > > > On Saturday, November 29, 2014, Mirko Friedenhagen < > > [email protected] <javascript:;>> > > wrote: > > > > > Alejandro, > > > > > > I have a completely different approach as we use a staging maven > > repository > > > anyway: > > > - make sure your workspace has no extra files by using your SCM clean > > > function. > > > - only run mvn release:prepare with the following preparationGoals > > property > > > -DperformRelease=true -DinstallAtEnd=true -DdeployAtEnd=true clean > deploy > > > - this ensures that only the tested and successfully deployed version > of > > > your software gets the tag. > > > - I expect tagging to be the least dangerous part of the process > compared > > > to tests, integration tests or the whole maven run with all it's > plugins. > > > - additionally this speeds up the whole process. > > > > > > But you are not building the checked out tag. If there are ignores that > > ignore files that get incorporated in the build you could have a > > non-reproducible build. > > > > (For example, I have a build (zendesk-java-client) where there is a > > .gitignore in src/test/resources to allow testing with a .properties file > > containing the credentials of a test zendesk. That gets released to > > Central. If I had a source assembly as part of it (I cannot recall, I > think > > I do though) then releasing your way would publish the credentials to > > Central in that source bundle... Better would be to have preparationGoals > > trivial (ie `initialize`) and then don't push the tag until the very > end... > > (Though in my case I keep both as I want the additional tests to run with > > the credentials and the standard tests to run without so that anyone else > > can still build from the tag). The point being that most people just > don't > > see all the good stuff the release plugin does for you by default and > > instead they try to hack around it... Your trick may work for you, but we > > can't let people think it should work for everyone and every case) > > > > > > > Regards > > > Mirko > > > -- > > > Sent from my mobile > > > On Nov 28, 2014 7:49 PM, <[email protected] > <javascript:;> <javascript:;>> > > > wrote: > > > > > > > That's good to know Robert, thank you > > > > > > > > I will add that to our release dryrun and hopefully it will catch > more > > of > > > > the uncaught problems early on > > > > > > > > Alejandro Endo | Software Designer/Concepteur de logiciels > > > > > > > > > > > > > > > > > > > > > > > > From: "Robert Scholte" <[email protected] <javascript:;> > <javascript:;>> > > > > To: "Maven Users List" <[email protected] <javascript:;> > <javascript:;>>, > > > > Date: 2014-11-28 12:46 PM > > > > Subject: Re: release plugin issue > > > > > > > > > > > > > > > > Op Fri, 28 Nov 2014 00:54:29 +0100 schreef > > > > <[email protected] <javascript:;> <javascript:;>>: > > > > > > > > > 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] > <javascript:;> > > > <javascript:;> > > > > For additional commands, e-mail: [email protected] > <javascript:;> > > > <javascript:;> > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > -- > > Sent from my phone > > > -- Sent from my phone
