Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
2.5.3
-
None
-
None
Description
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
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).
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] would suppress all pushes from being committed including the tag and nextsnapshot commits, and so would not work.
Attachments
Issue Links
- depends upon
-
SCM-970 Have separate APIs for distributed and centralized version control
- Open