fix: chain docker publish from release workflow#116
Merged
Conversation
GitHub's anti-recursion rule prevents workflows from triggering other workflows when acting as GITHUB_TOKEN. publish-release.yml pushes the release tag with the default token, so the push:tags:v* trigger on publish-docker.yml never fires. Result: v1.11.0 through v1.14.3 all published to npm but no Docker image reached GHCR, and the v1.14.3 OOM fix never made it to the Railway service pulling ghcr.io/copilotkit/aimock:latest. Fix by explicitly dispatching publish-docker.yml via `gh workflow run --ref <TAG>` after the npm publish step succeeds. This does not depend on tag-trigger behavior and is guarded by the same steps.check.outputs.published == 'false' condition as the publish, so Docker only builds when npm publish actually happened. Also restore the workflow_dispatch trigger on publish-docker.yml (added in 486ccd9, inadvertently removed in 63aab1e); `gh workflow run` requires workflow_dispatch on the ref being invoked. The existing push:tags:v* trigger stays as belt-and-suspenders for anyone pushing tags manually from a local clone with a PAT. Option chosen: explicit chain over PAT or workflow_call. Least invasive (no new secrets, no cross-workflow refactor), most observable (the dispatch shows up as a discrete step in the release run), and the failure mode is clearly visible in the release workflow log.
commit: |
jpr5
added a commit
that referenced
this pull request
Apr 18, 2026
## Problem
`gh release create` is invoked without `--latest`, leaving GitHub's
default selector to decide which Release wears the "Latest" badge. When
other Release objects exist (notably the floating `v1` Release that has
tracked the major version), GitHub can race and flip the badge to a
non-semver release unpredictably.
## Fix
Add `--latest` to the `gh release create` invocation in
`publish-release.yml` so every future semver release unambiguously
claims Latest.
```diff
- gh release create "${TAG}" --generate-notes --title "${TAG}" --verify-tag
+ gh release create "${TAG}" --generate-notes --title "${TAG}" --verify-tag --latest
```
## Notes
- Orthogonal to #116 (Docker publish chain). Independently useful.
- The floating `v1` Release object is being deleted separately as a
one-shot ops action; this PR is **defense in depth** so the badge can
never race again, regardless of what other Release objects exist now or
in the future.
- Single-line YAML change. Format/lint/build/test all pass locally.
**Do not merge. Do not enable auto-merge.**
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
1 participant
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.
Bug
publish-release.ymlpushes thev*release tag using the defaultGITHUB_TOKEN. Per GitHub's anti-recursion rule, workflow-created tags pushed withGITHUB_TOKENdo not trigger downstream workflows. As a result, thepush: tags: [v*]trigger onpublish-docker.ymlnever fires on automated releases.Evidence: v1.11.0 through v1.14.3 all published cleanly to npm, but the last successful GHCR publish was for v1.10.0. We only caught this when the v1.14.3 OOM fix never reached the Railway service pulling
ghcr.io/copilotkit/aimock:latest.Fix
After the npm publish step in
publish-release.ymlsucceeds, explicitly invokepublish-docker.ymlviagh workflow run publish-docker.yml --ref v$VERSION. Guarded by the samesteps.check.outputs.published == 'false'condition, so Docker only builds when npm publish actually happened.Two supporting changes:
actions: writeto the release job permissions (required to dispatch another workflow).workflow_dispatch:onpublish-docker.yml— it was added in 486ccd9 but inadvertently removed in 63aab1e.gh workflow run --ref <TAG>requiresworkflow_dispatchto be present on the ref being dispatched.The existing
push: tags: v*trigger onpublish-docker.ymlstays in place as belt-and-suspenders for anyone pushing tags manually from a local clone with a PAT.Why this option over the alternatives
gh workflow run) — picked. Least invasive, no new secrets, most observable. The dispatch is a discrete named step in the release run, so failures are immediately visible in the log. Doesn't depend on tag-trigger semantics at all.workflow_callrefactor): Strongest coupling but forces us to refactorpublish-docker.ymlto exposeworkflow_callalongsidepush/pull_request/workflow_dispatch, and changes the run topology (nested job vs. separate workflow run). Overkill for what is fundamentally a trigger-chaining bug.Verification
On the next release after this merges, the release run should show:
v1.x.yis pushedTrigger Docker publish workflowdispatchespublish-docker.ymlagainstv1.x.ypublish-docker.ymlrun appears under Actions with trigger =workflow_dispatch, ref =v1.x.yghcr.io/copilotkit/aimock:1.x.yand:latestappear under PackagesA reviewer can also manually confirm the dispatch path right now by running:
(Note: another agent is handling v1.14.3 specifically — don't trigger from this PR.)
Local checks
pnpm run format:check— cleanpnpm run lint— cleanpnpm run build— cleanpnpm run test— 2461/2461 passing