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
Hello Mirko.
I've been there too. With builds that take 4-6 hours to run, hundreds of
modules, and lots of testing failures, some intermittent, some not. In my
case, I had a very tempremental ESB/Process Server's serviceDeploy to
contend with. I added a retry option into the was6:serviceDeploy
B
On Monday, April 13, 2015, Chris Graham chrisgw...@gmail.com wrote:
Hello Mirko.
I've been there too. With builds that take 4-6 hours to run, hundreds of
modules, and lots of testing failures, some intermittent, some not. In my
case, I had a very tempremental ESB/Process Server's
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
mfriedenha...@apache.org wrote:
Hello,
we now have pushChanges and localCheckout in the release:prepare goal.
IMO pushing commits and tags after a successful
On Sat, Apr 11, 2015 at 7:06 PM, Mirko Friedenhagen mfriedenha...@gmail.com
wrote:
Stephen,
this does sound even more reasonable. release.properties is deleted at the
end of perform, so the goal could only rely on information in the pom.
Doesn't release:clean effectively do that?
I could see value in a release:finalize goal that is a no-op for non-DCVS
but does a push changes for DCVS
It would mean that you could go
mvn release:prepare release:perform release:finalize
in one command to close it all out
On 10 April 2015 at 22:36, Robert Scholte rfscho...@apache.org
Stephen,
this does sound even more reasonable. release.properties is deleted at the
end of perform, so the goal could only rely on information in the pom.
Regards
Mirko
--
Sent from my mobile
On Apr 11, 2015 9:40 AM, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
I could see value in
I think a `finalizeGoals`, defaulting to `initialize` would suffice to give
people enough of a hook. You could then either implement a custom lifecycle
or attach the blue-green toggle actions to a special profile and the push
changes would be part of the default impl of the mojo.
That would give
On Saturday, April 11, 2015, Hervé BOUTEMY herve.bout...@free.fr wrote:
Le samedi 11 avril 2015 12:31:03 Stephen Connolly a écrit :
I think a `finalizeGoals`, defaulting to `initialize` would suffice to
give
perhaps an autoFinalize boolean too, by default true, for people
requiring
the
I've been thinking of a finalize as well, as something which could be
executed if a vote/stage has passed.
But those actions differ between organizations, which would mean either
introduce a lot of hooks or give an API so users can write their own
finalize phases
Op Sat, 11 Apr 2015
Le samedi 11 avril 2015 12:31:03 Stephen Connolly a écrit :
I think a `finalizeGoals`, defaulting to `initialize` would suffice to give
perhaps an autoFinalize boolean too, by default true, for people requiring
the simple current 2-phase release process
people enough of a hook. You could then
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.
What do you think about something like
Hmmm, no so sure about that.
The whole concept is that 'prepare' should do all the scm actions.
'perform' should only do a checkout from the tag and run 'mvn deploy'.
There should be as less as possible actions after uploading the artifacts
to a repository manager.
Did you ever face issues with
13 matches
Mail list logo
