-
-
Notifications
You must be signed in to change notification settings - Fork 2
Detect whether a release is being rolled back #13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
If a commit is pushed which rolls back a release candidate and hence downgrades the version of the package in question, then this action will regard it as a release commit. This isn't right, and we should do something about it. However, we don't simply want to ignore this information, because it may come in handy (for instance, if we want to automatically remove the GitHub release/tag or verify the changelog in a different way). Therefore, this commit adds a new output, `COMMIT_TYPE`, which can either be `release`, `release-rollback`, or unset (not a release or a release rollback). In fact, this commit makes this output recommended and deprecates `IS_RELEASE`.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Semver Prerelease Parsing Fails
The semver comparison script incorrectly handles prerelease versions that contain dots (e.g., "1.0.0-alpha.1"). It splits the full version string by dots before extracting the prerelease, causing parts of the prerelease identifier (like the '1' in 'alpha.1') to be incorrectly parsed as numeric version components. This leads to erroneous version comparisons.
scripts/compare-semver-versions.sh#L9-L30
action-is-release/scripts/compare-semver-versions.sh
Lines 9 to 30 in e0c2c5f
| # Split versions into major.minor.patch and prerelease | |
| IFS='.' read -a v1_parts <<< "$version1" | |
| IFS='.' read -a v2_parts <<< "$version2" | |
| # Extract prerelease parts if they exist | |
| local v1_prerelease="" | |
| local v2_prerelease="" | |
| # Check if version1 has prerelease (contains hyphen) | |
| if [[ "$version1" == *"-"* ]]; then | |
| v1_prerelease="${version1#*-}" | |
| # Remove prerelease from parts array | |
| v1_parts=("${v1_parts[@]%-*}") | |
| fi | |
| # Check if version2 has prerelease (contains hyphen) | |
| if [[ "$version2" == *"-"* ]]; then | |
| v2_prerelease="${version2#*-}" | |
| # Remove prerelease from parts array | |
| v2_parts=("${v2_parts[@]%-*}") | |
| fi |
Was this report helpful? Give feedback by reacting with 👍 or 👎
If a commit is pushed which rolls back a release candidate and hence downgrades the version of the package in question, then this action will regard it as a release commit. Now, this doesn't affect
core(e.g. https://github.com/MetaMask/core/actions/runs/16173551572/job/45653343692) because we also pass a commit message prefix, and release rollbacks don't follow that pattern, so they get rejected by this action.However, we may actually want to know about release rollbacks. For instance, it would be useful to automatically remove the GitHub release/tag if a release is rolled back, or verify that the version being rolled back is also removed from the changelog. We can't do this well right now without repeating logic.
Therefore, this commit adds a new output,
COMMIT_TYPE, which can either berelease,release-rollback, or "normal" (not a release or a release rollback). In fact, this commit promotes this output as the one to use in the README and deprecatesIS_RELEASE.Closes #1.