fix: only tag docker release after corresponding image is pushed

[timtalbot]

Description

Both release.yml and build.yml trigger on push to main. build.yml takes ~10 min to build and push :latest, while tag-docker-release completes in ~15 seconds. This meant every release tag was consistently one version behind.

• Fix race condition where tag-docker-release pulls :latest before build.yml has finished pushing it, causing every versioned Docker tag to point to the previous release's image
• Add a wait step that uses gh run watch to block until build.yml completes for the exact commit SHA before pulling and re-tagging :latest
• Skip the wait on workflow_dispatch so manual re-tagging (recovery) still works immediately
• Align paths-ignore between release.yml and build.yml to prevent release triggering without a corresponding build
• Add 15-minute timeout on the wait step

Category of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Build: a code change that affects the build system or external dependencies
• Performance: a code change that improves performance
• Refactor: a code change that neither fixes a bug nor adds a feature
• Documentation: documentation changes
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

• I have run just test and all tests pass
• I have reviewed my own diff and added inline comments on lines I want reviewers to focus on or that I am uncertain about

[claude]

Claude finished @timtalbot's task —— View job

---

Review: .github/workflows/release.yml

Good fix — the race condition diagnosis is correct and using gh run watch to block on the exact commit's build run is clean and straightforward.

---

1. paths-ignore alignment is incomplete

release.yml retains .github/workflows/** in paths-ignore but build.yml does not. A workflow-only push to main would trigger build.yml (new :latest) but skip release.yml — so tag-docker-release wouldn't run. In practice this is probably harmless (no semantic-release = no new tag = nothing to do), but it contradicts the PR description's "align paths-ignore" claim. Worth either truly aligning them or noting the intentional divergence in a comment.

2. Latent race on gh run list lookup

Both workflows trigger on push, but release.yml's release job (semantic-release) must complete before tag-docker-release starts. It's possible that when the gh run list --commit call executes, the build.yml run hasn't been registered by GitHub's API yet. Semantic-release likely takes long enough to mask this today, but a small retry loop would make it robust against future speedups:

for i in $(seq 1 5); do
  RUN_ID=$(gh run list \
    --workflow="build.yml" \
    --branch=main \
    --commit="${{ github.sha }}" \
    --limit=1 \
    --json databaseId \
    --jq '.[0].databaseId')
  [ -n "$RUN_ID" ] && break
  echo "Build run not found yet, retrying in 10s..."
  sleep 10
done

3. Error message is clear — The ::error:: annotation when RUN_ID is empty is good UX in the Actions UI.

4. workflow_dispatch skip — Skipping the wait for manual recovery is a sensible escape hatch. Inline comments explaining "why" are helpful.

5. Self-review checklist — Per repo conventions, the PR author is expected to review their own diff and add inline comments on areas of concern. The checklist items in the PR body are unchecked.

---

[stevenolen]

nice find!