Skip to content

fix(ci): chain-image parses tag from scrape-pack run-name#219

Merged
laradji merged 1 commit into
mainfrom
emdash/feat-fix-ci-chain-image-s-inputs-209-g8c85
May 7, 2026
Merged

fix(ci): chain-image parses tag from scrape-pack run-name#219
laradji merged 1 commit into
mainfrom
emdash/feat-fix-ci-chain-image-s-inputs-209-g8c85

Conversation

@laradji
Copy link
Copy Markdown
Owner

@laradji laradji commented May 7, 2026

Closes #218.

Summary

  • chain-image.yml's Resolve tag from upstream run step was reading gh api .../runs/<id> --jq '.inputs.tag', which always returns null — the runs REST endpoint does NOT expose workflow_dispatch inputs. Latent since refactor(ci): split docker image publish out of scrape-pack into its own concern-per-file workflow #209; surfaced after fix(ci): chain-release uses PAT so scrape-pack completion fires chain-image #217 made chain-image fire reliably (every release v0.7.0–v0.7.3 needed a manual gh workflow run docker-publish.yml because chain-image's auto-dispatch was always skipped).
  • scrape-pack.yml gains a top-level run-name: that embeds inputs.tag: scrape-pack (v<x.y.z>) for tagged runs, scrape-pack (cache-warm) for empty-tag dispatches.
  • chain-image.yml parses the tag back out of github.event.workflow_run.display_title instead of hitting the runs API. Stable-tag regex (^v[0-9]+\.[0-9]+\.[0-9]+$) and cache-warm skip gate preserved exactly. Old misleading comment about "the inputs field on the run JSON" deleted per the issue AC.

Test plan

  • python3 -c "import yaml; yaml.safe_load(open('.github/workflows/scrape-pack.yml'))" — OK
  • python3 -c "import yaml; yaml.safe_load(open('.github/workflows/chain-image.yml'))" — OK
  • Regex sanity-checked locally against four inputs: scrape-pack (v0.7.4) → tag=v0.7.4, scrape-pack (cache-warm) → cache-warm gate, scrape-pack (v1.2.3-rc1) → stable-tag-filter skip, bare scrape-pack (legacy in-flight runs) → cache-warm gate.
  • After merge: probe with gh workflow run scrape-pack.yml --ref main -f lib="" -f tag="" → chain-image's Resolve-tag step should log "cache-warm path; skipping".
  • After merge: probe with gh workflow run scrape-pack.yml --ref main -f lib="" -f tag=v0.7.3 → chain-image's Dispatch docker-publish.yml step conclusion should be success (not skipped), and a fresh docker-publish run should appear shortly after.
  • End-to-end validation: tag v0.7.4 — full chain (release → chain-release → scrape-pack → chain-image → docker-publish) must complete with no operator dispatch. This is the issue's Definition of Done.

The `gh api .../runs/<id> --jq '.inputs.tag'` read in chain-image's
Resolve-tag step always returns null — the runs REST endpoint does NOT
expose workflow_dispatch inputs. Latent since #209; surfaced once #217
made chain-image actually fire.

Embed inputs.tag in scrape-pack.yml's top-level run-name (`scrape-pack
(v<x.y.z>)` or `scrape-pack (cache-warm)`), then parse it out of
`github.event.workflow_run.display_title` on the chain-image side.
Stable-tag filter and cache-warm gate preserved exactly.

Closes #218.
@laradji laradji merged commit 4853588 into main May 7, 2026
4 checks passed
@laradji laradji deleted the emdash/feat-fix-ci-chain-image-s-inputs-209-g8c85 branch May 7, 2026 19:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

fix(ci): chain-image's '.inputs.tag' read returns empty — docker-publish never auto-dispatched since #209

1 participant