[
https://issues.apache.org/jira/browse/MRELEASE-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Burrell updated MRELEASE-1030:
-------------------------------------
Description:
h2. Scenario:
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
h2. Problem:
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).
h2. 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.
If this plugin is built on the scm code base then I suspect this is down to
generic usage of the scm, 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 allowing it to be configured in the release
plugin.
I think `pushChanges` [here|#l95]] would suppress all pushes from being
committed including the tag and nextsnapshot commits, and so would not work.
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).
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
> 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
>
> h2. Scenario:
> 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
> h2. Problem:
> 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).
> h2. 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.
> If this plugin is built on the scm code base then I suspect this is down to
> generic usage of the scm, 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 allowing it to be configured in
> the release plugin.
> I think `pushChanges` [here|#l95]] would suppress all pushes from being
> committed including the tag and nextsnapshot commits, and so would not work.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
