[
https://issues.apache.org/jira/browse/MRELEASE-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Burrell updated MRELEASE-1030:
-------------------------------------
Description:
When performing release:prepare the following action is taken.
* solidify releases
* commit and push
* tag this commit
* push tag
* move to next snapshot
* commit and push
This behaviour in a git based CI environment results in additional unnecessary
builds as an untagged commit is delivered, quickly followed by the same commit
in tagged form. Build systems are setup to look for tagged commits to initiate
a release process, but the double push results in a 2 builds: (the same code,
but one untagged).
proposal:
The commit and push that happens in stage 2 above should be a commit only.
the push should be a push of the tag (which implicitly pushes the commit).
To maintain backward compatibility this behaviour should be a flag, with the
default to current behaviour
I suspect this issue is caused by generic usage of scm info, without
consideration of the nuances of git. (Pushing after every commit). The scm
plugin does indeed have a flag for this purpose but we are not making use of it
or exposing it at the release plugin level
was:
When performing release:prepare the following action is taken.
* solidify releases
* commit and push
* tag this commit
* push tag
* move to next snapshot
* commit and push
This behaviour in a git based CI environment results in additional unnecessary
builds as an untagged commit is delivered, quickly followed by the same commit
in tagged form. Build systems are setup to look for tagged commits to initiate
a release process, but the double push results in a 2 builds: (the same code,
but one untagged).
The commit and push that happens in stage 2 above should be a commit only.
the push should be a push of the tag (which implicitly pushes the commit).
To maintain backward compatibility this should be a flag.
I suspect this issue is caused by generic usage of scm info, without
consideration of the nuances of git. (Crushing after every commit). The scm
plugin does indeed have a flag for this purpose but we are not making use of it
or exposing it at the release plugin level
> Introduce flag to push once, not twice, during release:prepare
> --------------------------------------------------------------
>
> Key: MRELEASE-1030
> URL: https://issues.apache.org/jira/browse/MRELEASE-1030
> Project: Maven Release Plugin
> Issue Type: Improvement
> Components: prepare
> Affects Versions: 2.5.3
> Reporter: Daniel Burrell
> Priority: Major
>
> When performing release:prepare the following action is taken.
> * solidify releases
> * commit and push
> * tag this commit
> * push tag
> * move to next snapshot
> * commit and push
>
> This behaviour in a git based CI environment results in additional
> unnecessary builds as an untagged commit is delivered, quickly followed by
> the same commit in tagged form. Build systems are setup to look for tagged
> commits to initiate a release process, but the double push results in a 2
> builds: (the same code, but one untagged).
> proposal:
> The commit and push that happens in stage 2 above should be a commit only.
> the push should be a push of the tag (which implicitly pushes the commit).
> To maintain backward compatibility this behaviour should be a flag, with the
> default to current behaviour
> I suspect this issue is caused by generic usage of scm info, without
> consideration of the nuances of git. (Pushing after every commit). The scm
> plugin does indeed have a flag for this purpose but we are not making use of
> it or exposing it at the release plugin level
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
