Fixed ci-release.yml startup_failure blocking tag releases#27473
Conversation
WalkthroughThe 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #27473 +/- ##
==========================================
- Coverage 72.72% 72.72% -0.01%
==========================================
Files 1556 1556
Lines 125669 125669
Branches 15135 15135
==========================================
- Hits 91389 91387 -2
- Misses 33326 33327 +1
- Partials 954 955 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|



Summary
The v6.31.0 release workflow failed with
startup_failureand never published: run 24573212819. Zero jobs created, no logs. This wasci-release.yml's first real firing sincedd17126f21split release CI into a reusable-workflow call.Root cause
When a caller job invokes a reusable workflow, its
permissions:block cannot exceed the calling workflow's top-level permissions.ci-release.ymlhad no top-levelpermissions:block, so the ceiling fell back to the repo default (default_workflow_permissions: write). That default includescontents: writeandpackages: write, butid-tokenis never in any default — OIDC must always be granted explicitly.The
ci:job then declaredid-token: write, exceeding the workflow ceiling. GitHub's graph validator rejected the run before scheduling anything.This never showed up on the PR CI for the split commit, because PR CI hits
ci.ymldirectly viapull_request, not throughci-release.yml. The bug was gated on an actualv*tag push.Fix
Add a top-level
permissions:block toci-release.ymlmatching the caller job's grant. The ceiling now includesid-token: write, the caller job's grant is≤the ceiling, validation passes.Also grant
actions: readat both the workflow and caller-job level.ci.yml'sjob_setupdeclares it fornrwl/nx-set-shas. That step is currently gated off on tag runs (if: env.IS_TAG != 'true'), so nothing breaks today ifactions:silently downgrades tononethrough the reusable-workflow cap — but granting it explicitly documents intent and avoids a latent trap if that gate is ever removed.Test plan
v0.0.0-testtag to a fork to confirm the workflow starts past validation