Skip to content

feat(workflow): defer ci-pending label until accepted is added#7881

Merged
BYK merged 3 commits intomainfrom
fix/poll-all-ci-pending
Apr 21, 2026
Merged

feat(workflow): defer ci-pending label until accepted is added#7881
BYK merged 3 commits intomainfrom
fix/poll-all-ci-pending

Conversation

@BYK
Copy link
Copy Markdown
Member

@BYK BYK commented Apr 21, 2026

Summary

Issues now stay label-free on open. Labels only appear once someone adds accepted to 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-pending forever without any feedback, not realizing they just needed to add accepted. The poller by design only processed ci-pending + accepted issues, so pre-approval sat in limbo.

Now: clean issue → acceptedci-pending appears with comment → ci-ready (publish) or ci-failed (retry).

Race condition fix

ci-pending.yml and auto-approve.yml both fire on issues: opened and run in parallel. If auto-approve added accepted before ci-pending.yml added ci-pending, publish.yml's publish job would fire with accepted && !ci-pending — publishing without CI verification.

Fix: publish gate now requires ci-ready (added by the poller after CI passes), not just the absence of ci-pending.

State machine

opened → (no labels)
accepted added (human or auto-approve):
  waiting-for-ci → adds ci-pending, enables poller, triggers it, comments
  publish job    → skipped (needs ci-ready)

poller checks CI:
  CI passes → ci-pending → ci-ready → publish fires
  CI fails  → ci-pending → ci-failed, accepted removed, comment

accepted re-added after CI fix:
  waiting-for-ci → removes ci-failed, adds ci-pending, polls again

Changes

  • Delete ci-pending.yml — no longer triggers on issues: opened
  • publish.yml waiting-for-ci — absorbs the logic; fires on labeled: accepted, adds ci-pending (idempotent), removes ci-failed, enables poller variable, triggers poller
  • publish.yml publish gate — requires ci-ready instead of just !ci-pending

Migration

Issues already in ci-pending state from the old design (e.g. #7876) won't be picked up automatically — removing the ci-pending label manually and re-adding accepted will trigger the new flow.

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...
@BYK BYK requested a review from a team as a code owner April 21, 2026 09:41
Comment thread .github/workflows/publish.yml
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.
Comment thread .github/workflows/publish.yml Outdated
Copy link
Copy Markdown

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Fix All in Cursor

❌ 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.

Comment thread .github/workflows/publish.yml
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).
@BYK BYK merged commit b628539 into main Apr 21, 2026
10 checks passed
@BYK BYK deleted the fix/poll-all-ci-pending branch April 21, 2026 11:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant