On Saturday, November 29, 2014, Mirko Friedenhagen <[email protected]> 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:;>> > 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:;>> > > To: "Maven Users List" <[email protected] <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:;>>: > > > > > 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:;> > > For additional commands, e-mail: [email protected] > <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
