ci: call the registry dispatch from publish.yml instead of a trigger that cannot fire - #181
ci: call the registry dispatch from publish.yml instead of a trigger that cannot fire#181anilcancakir wants to merge 1 commit into
Conversation
…that cannot fire
`dispatch-to-registry.yml` declared `release: [published]`, but the release is
created inside publish.yml's github-release job by `gh release create` under
`GH_TOKEN: ${{ github.token }}`, and GitHub does not start workflow runs from
events raised by GITHUB_TOKEN. The trigger was added on 2026-08-03 and 1.4.0
was the first release after it, so it had one chance and missed: the run
history held nothing since 2026-08-03, and both entries there were
workflow_dispatch and the retired push trigger. The 1.4.0 skill reached
fluttersdk/ai only because it was dispatched by hand.
The failure is silent, which is the part worth fixing. The publish workflow
goes green either way and the only symptom is end users installing a skill one
version behind.
publish.yml now calls the workflow with `needs: github-release`. That removes
the cross-workflow event and also sequences the dispatch after pub.dev has
accepted the release rather than alongside it. The dead `release` trigger is
replaced by `workflow_call`; `workflow_dispatch` stays as the manual hatch.
Secrets are named rather than inherited: the called workflow needs exactly
two, and handing it the whole store would sit badly in a repo that pins every
action by SHA and runs zizmor over the result.
Also fixes the version-extraction guard in the same file. It tested the ref
against `^v[0-9]+\.[0-9]+\.[0-9]+`, but this repo tags without the prefix
(publish.yml matches '[0-9]+.[0-9]+.[0-9]+*'), so that branch never matched a
real tag and always fell through to pubspec.yaml. The fallback is correct on
master after a release bump, which is why it went unnoticed.
|
Warning Review limit reached
Next review available in: 57 minutes Limit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?Wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
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. 📢 Thoughts on this report? Let us know! |
1 participant
What
publish.ymlcallsdispatch-to-registry.ymldirectly after itsgithub-releasejob. Therelease: [published]trigger that workflow used to declare is gone, replaced byworkflow_call;workflow_dispatchstays as the manual escape hatch.Why
The trigger could never fire, and 1.4.0 proved it.
dispatch-to-registry.ymllistened forrelease: [published]. The release is created insidepublish.yml'sgithub-releasejob:GitHub does not start new workflow runs from events raised by
GITHUB_TOKEN. The trigger was added on 2026-08-03 and 1.4.0 (2026-08-21) was the first release after it, so it had exactly one chance:Nothing since. Both of those are the manual run and the retired
pushtrigger, so thereleasepath has never fired once. The 1.4.0 skill (2.12.0, plus the nine reference titles moved to the 1.4 line) reachedfluttersdk/aionly because it was dispatched by hand after the release.The shape of the failure is what makes it worth fixing rather than working around:
publish.ymlgoes green either way,dispatch-to-registry.ymlsimply never appears, and the only symptom is end users runningnpx skills add fluttersdk/ai --skill wind-uiand getting a skill one release behind. There is nothing red to notice.Why a call and not a different trigger
Adding
push: tagsto the dispatch workflow would also have fired, since a human tag push does trigger workflows. It was rejected because it runs in parallel withpublish.yml: the registry would be told about a version before pub.dev had accepted it, and if the publish job failed the registry would be ahead of the package.needs: github-releasegets the ordering for free and removes the cross-workflow event entirely, which is the part that was fragile.Secrets
Passed by name rather than
secrets: inherit. The called workflow needs exactlyREGISTRY_BOT_APP_IDandREGISTRY_BOT_PRIVATE_KEY, both now declaredrequired: trueunderworkflow_call.secrets, and handing it the whole secret store would sit badly in a repo that pins every action by SHA and runs zizmor plus scorecard over the result. Verified that the names declared on the callee match the names passed by the caller.Second bug in the same file
The version-extraction step tested the ref against
^v[0-9]+\.[0-9]+\.[0-9]+, but this repo tags without thevprefix:publish.ymlmatches[0-9]+.[0-9]+.[0-9]+*andCLAUDE.mdsaysgit tag X.Y.Z. So that branch could never match a real tag and every run fell through to readingpubspec.yaml. The fallback happens to give the right answer on master after a release bump, which is why it never surfaced. Now^v?, with the existing${GITHUB_REF_NAME#v}strip left in place since it is a no-op when there is no prefix.Verification
actionlintneeds Docker, which is not available on this machine, so it was not run locally; theWorkflows lintjob runs it on this PR. Locally I verified both files parse and that the call interface lines up on both sides:This PR touches
.github/workflows/**, sozizmor SASTactually reports here, unlike alib/-only PR.Other gates, unchanged by a workflow edit but run anyway:
dart format0 changed,dart analyzeno issues,flutter test1698 passed 1 skipped,check-docs.py0 issues.What this cannot verify
The fix only proves itself on the next real release, since
workflow_callruns only whenpublish.ymlruns. Until then the manualgh workflow run dispatch-to-registry.yml --ref masterremains the way to push a skill fix out between releases, and that path is untouched.