Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (nike.apache.org: domain of
 prvs=1409167490=Alejandro.Endo@grassvalley.com designates 12.161.118.90 as
 permitted sender)
In-Reply-To: 
 <CA+nPnMzCcM3o5v4utVFayzNjE5ro0PRZUT_wP=vU6qNkWL7__w@mail.gmail.com>
References: 
 <OFA2E1BE63.3A77C845-ON85257D9D.00817D6E-85257D9D.008354E4@belden.com>
	<op.xp1qawdgkdkhrr@robertscholte.dynamic.ziggo.nl>
 <CA+nPnMzCcM3o5v4utVFayzNjE5ro0PRZUT_wP=vU6qNkWL7__w@mail.gmail.com>
To: "Maven Users List" <users@maven.apache.org>
MIME-Version: 1.0
Subject: Re: release plugin issue
From: Alejandro.Endo@grassvalley.com
Message-ID: 
 <OF05371067.12DEC643-ON85257D9E.00651CBF-85257D9E.006739B2@belden.com>
Date: Fri, 28 Nov 2014 13:47:29 -0500
Content-Type: multipart/alternative;
 boundary="=_alternative 0067398485257D9E_="

--=_alternative 0067398485257D9E_=
Content-Type: text/plain; charset="US-ASCII"

But the problem has nothing to do with Jenkins

You can manually type mvn release:prepare release:perform -DdryRun=true 
and it will pass and then dryRun=false and it will fail

My point is about the default behaviour of a dry run not being realistic 
compared to a full release, which will make you miss problems that WILL 
fail the real release. And to make matters worse, if a real release fails, 
it leaves the repo in disarray. IMO it should really clean up to the same 
state as it was when the release was started. If this is not possible 
because you cannot easily revert changes in a SCM (or in other words, you 
cannot do the WHOLE release as a transaction) then at least there should 
be a realistic, non-persistent check for those operations that will give 
you a high degree of certainty that a real release will succeed. That's 
what a dry run is supposed to do. It will never be 100% sure (example, 
what if while deploying the release artifact the internet connection 
drops. This can't be checked by a successful dryRun) but it should be as 
real as possible, and right now the dryRun is so much simpler than the 
real release that it becomes meaningless. 

There are so many steps in a release (which is what makes this plugin so 
necessary) that there's many opportunities for failures: unstable 
dependencies, unstable parents, artifacts not being SNAPSHOTs, missing SCM 
tags (which are needed everywhere since SCM inheritance doesn't work well 
with git), errors in javadoc (that only since recently started failing the 
build), no write access in SCM repo, tag already existing in SCM repo, 
artifacts already existing in remote maven repo (i.e. accidental 
redeploys). All these I have actually encountered in real life in an 
enterprise setting. And i'm not saying all these are not detected by a 
default dryRun, some of them are. I just wanted to make the point that 
releasing has many potential failure points


Alejandro Endo | Software Designer/Concepteur de logiciels 


From:   Stephen Connolly <stephen.alan.connolly@gmail.com>
To:     Maven Users List <users@maven.apache.org>, 
Date:   2014-11-28 12:52 PM
Subject:        Re: release plugin issue


Ohhhh wait a sec.... you're using the evil job type...

http://javaadventure.blogspot.ie/2013/11/jenkins-maven-job-type-considered-evil.html


Well all bets are off then.... that will most likely royally screw you 
over

On 28 November 2014 at 17:45, Robert Scholte <rfscholte@apache.org> wrote:

> Op Fri, 28 Nov 2014 00:54:29 +0100 schreef 
<Alejandro.Endo@grassvalley.com
> >:
>
>
>  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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


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.

--=_alternative 0067398485257D9E_=--