[MRELEASE-1030] Introduce flag to push once, not twice, during release:prepare
- Dominant language
- Java
- Stars
- 128
- Forks
- 145
- Avg merge
- 7h 7m
- Merged PRs (30d)
- 3
Description
**[Daniel Burrell](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=danielburrell)** opened **[MRELEASE-1030](https://issues.apache.org/jira/browse/MRELEASE-1030?redirect=false)** and commented
## 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|#l95]] would suppress all pushes from being committed including the tag and nextsnapshot commits, and so would not work.
---
**Affects:** 2.5.3
**Issue Links:**
- [SCM-970](https://issues.apache.org/jira/browse/SCM-970) Have separate APIs for distributed and centralized version control
(_**"depends upon"**_)
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by tracing the release:prepare stages described in the issue and the existing pushChanges configuration, then review the linked SCM-970 dependency. Determine how the SCM API can commit without pushing while still pushing the tag, and how a new flag preserves the current default behavior. Done means the optional mode avoids the first push without suppressing the tag and next-snapshot commits.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, java
- Domain
- build-system, release
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100