feat(workflow): defer ci-pending label until accepted is added#7881
Merged
feat(workflow): defer ci-pending label until accepted is added#7881
Conversation
Issues now stay label-free until someone approves with accepted.
This fixes two UX/correctness issues:
1. Users were confused when issues sat in ci-pending forever without
any feedback when they just needed to add accepted. Now the issue
has no labels on open, and labels only appear once action is taken.
2. Race condition with auto-approve: previously auto-approve.yml could
add accepted before ci-pending.yml added ci-pending, causing the
publish job to fire without CI verification (gate was
!ci-pending, which was true at event time). The new gate requires
ci-ready which is only added by the poller after CI passes.
Changes:
- Delete ci-pending.yml (no longer triggers on issues: opened)
- publish.yml waiting-for-ci: now adds ci-pending + enables poller
when accepted is added, instead of ci-pending.yml doing it on open
- publish.yml publish job: gate requires ci-ready, not just !ci-pending
State machine:
opened → no labels
accepted → ci-pending, poller triggered, comment posted
CI passes → ci-ready → publish fires
CI fails → ci-failed, accepted removed, comment
accepted re-added after fix → ci-failed removed, ci-pending, poll...
If the previous publish attempt failed after the poller already added ci-ready, the label would still be present when accepted is re-added. The poller would then try to add ci-ready again (idempotent no-op), but since no labeled event fires, publish.yml would never trigger and the issue gets stuck. Fix: remove ci-ready alongside ci-failed in the Mark ci-pending step.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit a22fda8. Configure here.
Previously the publish job could race with waiting-for-ci when accepted was re-added to an issue that still had ci-ready from a previous attempt. Both jobs saw accepted+ci-ready in the event snapshot and ran in parallel, publishing without CI re-verification. Fix: narrow the event filter to ci-ready only. The happy path still works because the poller always adds ci-ready after checking CI (waiting-for-ci clears the old ci-ready first, guaranteeing a fresh labeled event).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Summary
Issues now stay label-free on open. Labels only appear once someone adds
acceptedto approve the release. Also fixes an auto-approve race condition that could publish without CI verification.UX problem (user-reported)
Users got confused when issues sat in
ci-pendingforever without any feedback, not realizing they just needed to addaccepted. The poller by design only processedci-pending + acceptedissues, so pre-approval sat in limbo.Now: clean issue →
accepted→ci-pendingappears with comment →ci-ready(publish) orci-failed(retry).Race condition fix
ci-pending.ymlandauto-approve.ymlboth fire onissues: openedand run in parallel. If auto-approve addedacceptedbeforeci-pending.ymladdedci-pending,publish.yml's publish job would fire withaccepted && !ci-pending— publishing without CI verification.Fix: publish gate now requires
ci-ready(added by the poller after CI passes), not just the absence ofci-pending.State machine
Changes
ci-pending.yml— no longer triggers onissues: openedpublish.ymlwaiting-for-ci— absorbs the logic; fires onlabeled: accepted, adds ci-pending (idempotent), removes ci-failed, enables poller variable, triggers pollerpublish.ymlpublishgate — requiresci-readyinstead of just!ci-pendingMigration
Issues already in
ci-pendingstate from the old design (e.g. #7876) won't be picked up automatically — removing theci-pendinglabel manually and re-addingacceptedwill trigger the new flow.