ci: add manual gem yank workflow#129
Conversation
Adds a workflow_dispatch workflow to yank (or un-yank) a published chargebee version from RubyGems, reusing the GEM_HOST_API_KEY secret. Requires re-typing the version to confirm to avoid accidental yanks. Co-authored-by: Cursor <cursoragent@cursor.com>
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
WalkthroughAdds a new GitHub Actions workflow ( ChangesYank Workflow
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant User
participant GitHubActions
participant RubyGems
User->>GitHubActions: Trigger workflow_dispatch (version, confirm, undo)
GitHubActions->>GitHubActions: Validate version == confirm and format
GitHubActions->>GitHubActions: Setup Ruby 3.0
GitHubActions->>RubyGems: gem yank chargebee -v VERSION [--undo]
RubyGems-->>GitHubActions: Yank/un-yank result
Related issues: None referenced. Related PRs: None referenced. Suggested labels: ci, workflow Suggested reviewers: None specified. Poem: 🐇 A rabbit taps the gem release, Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
.github/workflows/yank.yml (2)
22-29: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winNo
permissions:block set.This workflow doesn't need repo write access (no checkout, no git push), yet it inherits the default (often broad)
GITHUB_TOKENpermissions. Restrict to least privilege.🔒 Suggested fix
jobs: yank: runs-on: ubuntu-latest + permissions: + contents: read env: VERSION: ${{ inputs.version }}🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/yank.yml around lines 22 - 29, The yank workflow currently omits a permissions block, so it inherits broader default GITHUB_TOKEN access than needed. Add a least-privilege permissions setting to the yank job/workflow in the yank job definition, keeping only the minimal scopes required for the existing steps in yank.yml since there is no checkout or git push.
5-20: 🧹 Nitpick | 🔵 TrivialConsider an environment protection gate for approval before yanking.
Yanking permanently deletes the gem file from RubyGems.org's CDN and index — a largely irreversible, high-impact action. The confirm-retype only guards against typos, not against an unintended or unauthorized dispatch. Gating this job behind a GitHub
environment:with required reviewers would add a real approval checkpoint before execution.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/yank.yml around lines 5 - 20, Add an environment protection gate to the yanking workflow so the destructive release action requires approval before execution. Update the job that performs the yank/un-yank logic in the yanking workflow to use a GitHub environment with required reviewers, and keep the existing workflow_dispatch inputs such as version, confirm, and undo unchanged. Ensure the approval gate applies before the step that talks to RubyGems.org.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/yank.yml:
- Around line 16-20: The workflow currently exposes an unsupported undo/un-yank
path through the inputs and branch logic in the yank workflow. Remove the undo
input and any conditional handling tied to it in the workflow logic, and keep
only the standard yank behavior in the job flow; if an alternate un-yank process
is needed, move it to a separate manual support path outside the workflow.
---
Nitpick comments:
In @.github/workflows/yank.yml:
- Around line 22-29: The yank workflow currently omits a permissions block, so
it inherits broader default GITHUB_TOKEN access than needed. Add a
least-privilege permissions setting to the yank job/workflow in the yank job
definition, keeping only the minimal scopes required for the existing steps in
yank.yml since there is no checkout or git push.
- Around line 5-20: Add an environment protection gate to the yanking workflow
so the destructive release action requires approval before execution. Update the
job that performs the yank/un-yank logic in the yanking workflow to use a GitHub
environment with required reviewers, and keep the existing workflow_dispatch
inputs such as version, confirm, and undo unchanged. Ensure the approval gate
applies before the step that talks to RubyGems.org.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Enterprise
Run ID: 020361fa-466c-448e-b62b-658610fb0bd6
📒 Files selected for processing (1)
.github/workflows/yank.yml
| undo: | ||
| description: "Un-yank instead (re-list a previously yanked version)" | ||
| required: false | ||
| type: boolean | ||
| default: false |
There was a problem hiding this comment.
🎯 Functional Correctness | 🔴 Critical | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
sed -n '1,220p' .github/workflows/yank.ymlRepository: chargebee/chargebee-ruby
Length of output: 1901
🌐 Web query:
RubyGems yank undo support gem yank --undo rubygems.org documentation
💡 Result:
The --undo option for the gem yank command is no longer supported in RubyGems [1]. While earlier versions of RubyGems included an --undo flag to facilitate "unyanking" a gem, this functionality was removed around 2015 [1]. Consequently, modern versions of the RubyGems CLI do not recognize the --undo argument and will return an error if it is used [1]. There is no official "undo" mechanism for yanking a gem via the command-line interface [2][3]. If a gem version has been yanked, it is typically necessary to push a new version of the gem to the server to make it available again [3].
Citations:
- 1: Rubygems parity: Remove '--undo' option in 'gem yank' rubygems/gemstash#120
- 2: https://github.com/rubygems/guides/blob/main/command-reference.md
- 3: https://guides.rubygems.org/removing-a-published-gem/
Remove the undo path; gem yank --undo is unsupported by RubyGems.org.
This workflow exposes an option that modern RubyGems rejects, so the “un-yank” branch will fail in practice. Remove the input/branch or replace it with a manual support flow.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/yank.yml around lines 16 - 20, The workflow currently
exposes an unsupported undo/un-yank path through the inputs and branch logic in
the yank workflow. Remove the undo input and any conditional handling tied to it
in the workflow logic, and keep only the standard yank behavior in the job flow;
if an alternate un-yank process is needed, move it to a separate manual support
path outside the workflow.
2 participants
Adds a workflow_dispatch workflow to yank (or un-yank) a published chargebee version from RubyGems, reusing the GEM_HOST_API_KEY secret. Requires re-typing the version to confirm to avoid accidental yanks.
Added a manual GitHub Actions workflow to yank or un-yank a published
chargebeegem version from RubyGems. It validates the requested version, requires re-entering the version as confirmation, sets up Ruby, and usesGEM_HOST_API_KEYto run the appropriategem yankcommand.