feat(workflow): restore repo variable gate with dedicated poller app by BYK · Pull Request #7780 · getsentry/publish

BYK · 2026-04-13T10:54:54Z

Summary

Bring back the CI_POLLER_HAS_PENDING variable gate so the cron is truly zero-cost when idle — no runner provisioned at all.

Uses a dedicated GitHub App (CI_POLLER_APP_CLIENT_ID) for variable writes since neither GITHUB_TOKEN nor sentry-internal-app has the actions_variables:write permission. The app secret is in the production environment for branch protection.

How it works

Workflow	Trigger	What it does
`ci-pending.yml`	`issues: opened`	Adds `ci-pending` label (sentry-internal-app) + sets variable to `true` (poller app)
`ci-poller.yml`	`schedule: */5`	`if: vars.CI_POLLER_HAS_PENDING == 'true'` — skips when false (no runner). Checks CI, flips labels, sets variable to `false` when done.

Cost

Idle: zero — job if is false, no runner provisioned
Active: ~30s per cron tick while there are pending releases
Previous (without variable): ~10-15s per tick 24/7 even when idle

Pre-requisites (already done)

Repo variable: CI_POLLER_HAS_PENDING = false
Repo variable: CI_POLLER_APP_CLIENT_ID
Production environment secret: CI_POLLER_APP_PRIVATE_KEY

Bring back the CI_POLLER_HAS_PENDING variable gate so the cron is truly zero-cost when idle (no runner provisioned). Use a dedicated GitHub App (CI_POLLER_APP_CLIENT_ID) for variable access since neither GITHUB_TOKEN nor sentry-internal-app has the actions_variables:write permission. The app secret is stored in the production environment for branch protection. Flow: - ci-pending.yml: adds ci-pending label (sentry-internal-app) and sets CI_POLLER_HAS_PENDING=true (poller app) - ci-poller.yml: gated by if: vars.CI_POLLER_HAS_PENDING == "true", resets to "false" when all issues resolved (poller app)

- ci-poller.yml: split "disable poller" into two steps — GITHUB_TOKEN for gh issue list (read), poller token only for gh variable set (write). The poller app may only have actions_variables permission. - ci-pending.yml: reorder so label addition (critical) runs before poller token generation (non-critical). If the poller token step fails, the label is already applied.

…e condition

- Poller token step moved after CI check step so a token failure cannot block CI status checking - Cleanup steps (remaining check + disable) use if: always() so CI_POLLER_HAS_PENDING does not get stuck on "true" if the CI check step fails - Poller token only generated when needed (count == 0)

…est-effort steps - ci-poller.yml: disable step checks steps.poller-token.outcome == success so it does not run (and fail) when token generation failed - ci-pending.yml: poller token + variable set steps use continue-on-error since they are best-effort optimizations that must not block the critical label addition

cursor

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

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit c4f7d01. Configure here.}

When workflow_dispatch bypasses the variable gate (variable is "false") and finds pending issues that CI has not finished yet, the variable must be set back to "true" so subsequent cron ticks continue checking. Previously only the count==0 path was handled (disable). Now both paths are covered: enable when issues remain, disable when resolved.

BYK marked this pull request as ready for review April 13, 2026 10:57

BYK requested a review from a team as a code owner April 13, 2026 10:57