Chris,
it is _my personal_ experience, that running release:perform fails
more often than the taging/comitting steps in release:prepare.
- E.g. I run release:prepare and some plugins are only activated when
performRelease is set (checkstyle, rat, gpg, license-checker).
- You may argue that I just should activate the same profiles during
preparationGoals ("-DperformRelease=true clean verify") and be good.
- But we have multi-module builds, where tests takes several hours (a
problem of it's own, I know), so teams are not willing to run tests
during prepare *and* perform.
- I could advise them to run the tests during prepare only, however
this feels strange as the binaries are deploy are not the same.
- So I advise them to skip tests during prepare (you could even set
preparationGoals=clean).
- Then you may end with tags which never make it into production as a
test broke during release:perform.
- While this is no problem, when you only do release builds every
other day, other teams want to deploy continuously and then you are
left with a lot of non-deployed tags in your SCM after a while (or you
would need a procurement mechanism of tags which made it into
production).
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/
On Mon, Apr 13, 2015 at 3:48 AM, Chris Graham <[email protected]> wrote:
> I'm not actually sure of what problem you're trying to solve here.
>
> On Sat, Apr 11, 2015 at 6:49 AM, Mirko Friedenhagen <
> [email protected]> wrote:
>
>> Hello,
>>
>> we now have pushChanges and localCheckout in the release:prepare goal.
>> IMO pushing commits and tags after a successful release:perform or
>> release:stage would be a good thing then, as this will probably
>> succeed most of the times.
>>
>>
> I have a real problem with the word 'probably' here. As there will always
> be times when that is not the case, when things fail. Sometimes on a
> permanent basis, sometimes a temporary failure.
>
> What appears to be the case here, is that we've come up with a proposed
> solution to a problem that I have no clear idea about. Can someone please
> elaborate?
>
>
>
>> What do you think about something like pushChangesAfterPerform?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
