B
On Monday, April 13, 2015, Chris Graham 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 serviceDeploy to
> conte
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 goa
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
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 release:p
On Sat, Apr 11, 2015 at 7:06 PM, Mirko Friedenhagen 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?
> Regards
> Mirko
> --
>
On Saturday, April 11, 2015, Hervé BOUTEMY 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 simple current 2
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 th
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 e
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 09:38
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"
wrote:
> I could see value in a release:finalize goal 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 wrote:
> Hmmm, no so sur
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
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 pushChangesAfterPerfor
13 matches
Mail list logo
