ci: Add a workflow to undo/yank a release, if necessary#512
ci: Add a workflow to undo/yank a release, if necessary#512vishal-bala wants to merge 2 commits intomainfrom
Conversation
🛡️ Jit Security Scan Results
✅ No security findings were detected in this PR
Security scan by Jit
|
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
| run: | | ||
| set -euo pipefail | ||
| python -m pip install --upgrade pip twine | ||
| twine yank "${SPEC}" |
There was a problem hiding this comment.
twine yank is not a valid twine subcommand
High Severity
twine yank is not a valid subcommand. The twine CLI (latest version 6.1.0) only supports upload, check, and register subcommands. Running twine yank "${SPEC}" will fail with an unrecognized command error. PyPI yanking is currently only available through the PyPI web interface or by calling the PyPI API directly (e.g., via curl).
| owner: ${{ github.repository_owner }} | ||
|
|
||
| - name: Checkout repository | ||
| if: ${{ inputs.delete_git_tag }} |
There was a problem hiding this comment.
Release deletion silently fails without repo checkout context
Medium Severity
The checkout step is conditional on inputs.delete_git_tag, but the gh release view/gh release delete commands also depend on having a repo context. When delete_github_release is true but delete_git_tag is false, no checkout occurs, and gh cannot determine the base repository. Because the gh release view error is suppressed by >/dev/null 2>&1, the step silently falls through to the else branch printing "No GitHub release found," even though the release exists. The checkout condition needs to also account for delete_github_release, or the gh commands need an explicit --repo flag.
Additional Locations (1)
|
This approach doesn't feel like the most reliable way to go about this, and also on closer inspection, there doesn't seem to be an established programmatic way to yank a release. Ditching this for now in favour of keeping the process fairly manual. |
1 participant
Since we are moving to more automated releases, it makes sense (like in the case of 0.14.1) to have the option to undo a release that was incorrectly created. This should not be done lightly, but as a last resort.
A workflow is one option for this, but possibly not the best (due to permissioning).
Note
Medium Risk
Medium risk because it adds a privileged workflow that can delete GitHub releases/tags and yank packages from PyPI; misconfiguration or misuse could remove published artifacts. Changes are isolated to CI/release automation and lockfile metadata.
Overview
Adds a new manually-triggered
Undo ReleaseGitHub Actions workflow (release-undo.yml) that validates a typed confirmation/version, then can optionally delete the GitHub release, delete the remote git tag, and yankredisvl==<version>on PyPI using stored credentials.Updates
release-new.ymlto read the GitHub Appapp-idfromvars.RELEASE_BOT_APP_IDinstead of a hardcoded value, and bumpsuv.lockmetadata (includingredisvlto0.14.1).Written by Cursor Bugbot for commit e426d20. This will update automatically on new commits. Configure here.