Commit 341490e
authored
fix: chain docker publish from release workflow (#116)
## Bug
`publish-release.yml` pushes the `v*` release tag using the default
`GITHUB_TOKEN`. Per GitHub's anti-recursion rule, **workflow-created
tags pushed with `GITHUB_TOKEN` do not trigger downstream workflows**.
As a result, the `push: tags: [v*]` trigger on `publish-docker.yml`
never 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.yml` succeeds, explicitly
invoke `publish-docker.yml` via `gh workflow run publish-docker.yml
--ref v$VERSION`. Guarded by the same `steps.check.outputs.published ==
'false'` condition, so Docker only builds when npm publish actually
happened.
Two supporting changes:
- Added `actions: write` to the release job permissions (required to
dispatch another workflow).
- Restored `workflow_dispatch:` on `publish-docker.yml` — it was added
in 486ccd9 but inadvertently removed in 63aab1e. `gh workflow run --ref
<TAG>` requires `workflow_dispatch` to be present on the ref being
dispatched.
The existing `push: tags: v*` trigger on `publish-docker.yml` stays in
place as belt-and-suspenders for anyone pushing tags manually from a
local clone with a PAT.
## Why this option over the alternatives
- **Option A (explicit chain via `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.
- **Option B (use a PAT to push the tag):** Works, but requires storing
and rotating a long-lived secret, and the trigger is implicit (failures
look like "Docker workflow just didn't run"). Higher ongoing
maintenance.
- **Option C (`workflow_call` refactor):** Strongest coupling but forces
us to refactor `publish-docker.yml` to expose `workflow_call` alongside
`push`/`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:
1. npm publish succeeds
2. Tag `v1.x.y` is pushed
3. GitHub Release created
4. **New step**: `Trigger Docker publish workflow` dispatches
`publish-docker.yml` against `v1.x.y`
5. `publish-docker.yml` run appears under Actions with trigger =
`workflow_dispatch`, ref = `v1.x.y`
6. `ghcr.io/copilotkit/aimock:1.x.y` and `:latest` appear under Packages
A reviewer can also manually confirm the dispatch path right now by
running:
```
gh workflow run publish-docker.yml --ref v1.14.3 --repo CopilotKit/aimock
```
(Note: another agent is handling v1.14.3 specifically — don't trigger
from this PR.)
## Local checks
- `pnpm run format:check` — clean
- `pnpm run lint` — clean
- `pnpm run build` — clean
- `pnpm run test` — 2461/2461 passing
- YAML syntax validated on both workflow files2 files changed
+13
-0
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
7 | 7 | | |
8 | 8 | | |
9 | 9 | | |
| 10 | + | |
10 | 11 | | |
11 | 12 | | |
12 | 13 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
10 | 10 | | |
11 | 11 | | |
12 | 12 | | |
| 13 | + | |
13 | 14 | | |
14 | 15 | | |
15 | 16 | | |
| |||
81 | 82 | | |
82 | 83 | | |
83 | 84 | | |
| 85 | + | |
| 86 | + | |
| 87 | + | |
| 88 | + | |
| 89 | + | |
| 90 | + | |
| 91 | + | |
| 92 | + | |
| 93 | + | |
| 94 | + | |
| 95 | + | |
84 | 96 | | |
85 | 97 | | |
86 | 98 | | |
| |||
0 commit comments