You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Bernd Eckenfels <ec...@zusammenkunft.net> on 2014/10/31 17:26:52 UTC
maven-release got stuck when tag exists with released version in
pom
Hello,
one thing which bites me quite regularly with the maven release plugin
is the fact, that it will update the POMs to the release version then
commit them and then tag them. If the tagging fails (especially because
the tag existed already) then it will leave the head on a released
version number.
This is in my case a problem as I have to go through a gerrit release
to change it to a snapshot version to try again.
A good improvement would be to first check the existence of the tag.
This would not cover all error cases but the most common.
Another option (or in addition to that), a rollback action would be to
actually commit the updated POM with the old snapshot version again?
(just to warn people, in my case if an integration build is triggert on
the master which has configured jenkins to deploy (normally the
snapshots) it will happyly deply the released version).
Gruss
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven-release got stuck when tag exists with released version in
pom
Posted by Robert Scholte <rf...@apache.org>.
Op Sat, 01 Nov 2014 08:48:03 +0100 schreef Stephen Connolly
<st...@gmail.com>:
> On Friday, October 31, 2014, Robert Scholte <rf...@apache.org> wrote:
>
>> Hi,
>>
>> see MRELEASE-165 (release:prepare should fail if the tag already
>> exists)[1]
>> The main reason why it is still not implemented, is that this must be
>> solved in the SCM project. If we know how to do a valid(!) check of the
>> existence of a tag for the scm providers, we could start implementing
>> it.
>
>
> Actually we need only have the SCM api return a tristate:
>
> Exists
> Doesn't exist
> Don't know
>
> Then the default impl can return don't know, and the release plugin can
> implement the check via the SCM API immediately... That makes the problem
> just belong to the SCM API implementations
>
> ;-)
>
Exactly. The funny thing is, I can't find such a request in Jira for the
SCM project.
Based on the ScmManager[1] it'll probably look something like:
/**
* Verify if the tagName exists within the repository
*/
ExistsScmResult existsTag(ScmRepository repository, String tagName);
/**
* Verify if the branchName exists within the repository
*/
ExistsScmResult existsBranch(ScmRepository repository, String branchName);
[1]
http://maven.apache.org/scm/maven-scm-api/apidocs/org/apache/maven/scm/manager/ScmManager.html
>
>> My experience is, is that these kind of issues only happen at the start
>> of
>> a new project. Once it works, it'll all stay fine.
>>
>> About the rollback: it's already there: release:rollback[2]
>> And it works just as you described. However, if you do the release with
>> the Jenkins m2-release-plugin, that plugin in still missing the rollback
>> option[3].
>>
>> thanks,
>> Robert
>>
>> [1] https://jira.codehaus.org/browse/MRELEASE-165
>> [2] http://maven.apache.org/maven-release/maven-release-plugin/
>> rollback-mojo.html
>> [3] https://issues.jenkins-ci.org/browse/JENKINS-8038
>>
>> Op Fri, 31 Oct 2014 17:26:52 +0100 schreef Bernd Eckenfels <
>> ecki@zusammenkunft.net>:
>>
>> Hello,
>>>
>>> one thing which bites me quite regularly with the maven release plugin
>>> is the fact, that it will update the POMs to the release version then
>>> commit them and then tag them. If the tagging fails (especially because
>>> the tag existed already) then it will leave the head on a released
>>> version number.
>>>
>>> This is in my case a problem as I have to go through a gerrit release
>>> to change it to a snapshot version to try again.
>>>
>>> A good improvement would be to first check the existence of the tag.
>>> This would not cover all error cases but the most common.
>>>
>>> Another option (or in addition to that), a rollback action would be to
>>> actually commit the updated POM with the old snapshot version again?
>>>
>>> (just to warn people, in my case if an integration build is triggert on
>>> the master which has configured jenkins to deploy (normally the
>>> snapshots) it will happyly deply the released version).
>>>
>>> Gruss
>>> Bernd
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven-release got stuck when tag exists with released version in pom
Posted by Stephen Connolly <st...@gmail.com>.
On Friday, October 31, 2014, Robert Scholte <rf...@apache.org> wrote:
> Hi,
>
> see MRELEASE-165 (release:prepare should fail if the tag already exists)[1]
> The main reason why it is still not implemented, is that this must be
> solved in the SCM project. If we know how to do a valid(!) check of the
> existence of a tag for the scm providers, we could start implementing it.
Actually we need only have the SCM api return a tristate:
Exists
Doesn't exist
Don't know
Then the default impl can return don't know, and the release plugin can
implement the check via the SCM API immediately... That makes the problem
just belong to the SCM API implementations
;-)
> My experience is, is that these kind of issues only happen at the start of
> a new project. Once it works, it'll all stay fine.
>
> About the rollback: it's already there: release:rollback[2]
> And it works just as you described. However, if you do the release with
> the Jenkins m2-release-plugin, that plugin in still missing the rollback
> option[3].
>
> thanks,
> Robert
>
> [1] https://jira.codehaus.org/browse/MRELEASE-165
> [2] http://maven.apache.org/maven-release/maven-release-plugin/
> rollback-mojo.html
> [3] https://issues.jenkins-ci.org/browse/JENKINS-8038
>
> Op Fri, 31 Oct 2014 17:26:52 +0100 schreef Bernd Eckenfels <
> ecki@zusammenkunft.net>:
>
> Hello,
>>
>> one thing which bites me quite regularly with the maven release plugin
>> is the fact, that it will update the POMs to the release version then
>> commit them and then tag them. If the tagging fails (especially because
>> the tag existed already) then it will leave the head on a released
>> version number.
>>
>> This is in my case a problem as I have to go through a gerrit release
>> to change it to a snapshot version to try again.
>>
>> A good improvement would be to first check the existence of the tag.
>> This would not cover all error cases but the most common.
>>
>> Another option (or in addition to that), a rollback action would be to
>> actually commit the updated POM with the old snapshot version again?
>>
>> (just to warn people, in my case if an integration build is triggert on
>> the master which has configured jenkins to deploy (normally the
>> snapshots) it will happyly deply the released version).
>>
>> Gruss
>> Bernd
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Sent from my phone
Re: maven-release got stuck when tag exists with released version in
pom
Posted by Robert Scholte <rf...@apache.org>.
Hi,
see MRELEASE-165 (release:prepare should fail if the tag already exists)[1]
The main reason why it is still not implemented, is that this must be
solved in the SCM project. If we know how to do a valid(!) check of the
existence of a tag for the scm providers, we could start implementing it.
My experience is, is that these kind of issues only happen at the start of
a new project. Once it works, it'll all stay fine.
About the rollback: it's already there: release:rollback[2]
And it works just as you described. However, if you do the release with
the Jenkins m2-release-plugin, that plugin in still missing the rollback
option[3].
thanks,
Robert
[1] https://jira.codehaus.org/browse/MRELEASE-165
[2]
http://maven.apache.org/maven-release/maven-release-plugin/rollback-mojo.html
[3] https://issues.jenkins-ci.org/browse/JENKINS-8038
Op Fri, 31 Oct 2014 17:26:52 +0100 schreef Bernd Eckenfels
<ec...@zusammenkunft.net>:
> Hello,
>
> one thing which bites me quite regularly with the maven release plugin
> is the fact, that it will update the POMs to the release version then
> commit them and then tag them. If the tagging fails (especially because
> the tag existed already) then it will leave the head on a released
> version number.
>
> This is in my case a problem as I have to go through a gerrit release
> to change it to a snapshot version to try again.
>
> A good improvement would be to first check the existence of the tag.
> This would not cover all error cases but the most common.
>
> Another option (or in addition to that), a rollback action would be to
> actually commit the updated POM with the old snapshot version again?
>
> (just to warn people, in my case if an integration build is triggert on
> the master which has configured jenkins to deploy (normally the
> snapshots) it will happyly deply the released version).
>
> Gruss
> Bernd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org