Development record
the release chain runs with an empty secrets context, because auto-release.yml passes none to release.yml. A called workflow's secrets context is ONLY what its caller passes. A job inside one that declares environment: gets the environment APPLIED — GitHub creates a deployment record for it — and still resolves none of that environment's secrets unless inherit unlocked the context first. release.yml has carried 'secrets: inherit' on its call to site.yml since v0.6.3; auto-release.yml's call to release.yml carried no secrets line at all, so the chain ran empty from the top and the production deploy failed on a credential that was never conveyed, on v0.6.2, v0.6.3 and v0.6.5. NOT v0.6.4: that release's render failed on an unfenced code block in a record and its deploy was SKIPPED, so it never reached the credential at all (run 32765800591; the iss-2608241845109280 defect). Verified from the release runs rather than assumed — v0.6.2 run 32657507210, v0.6.3 run 32674659520 and v0.6.5 run 32777924919 each show render success and deploy failure. Measured on a canary environment secret through the same two-level shape: a top-level job declaring the environment saw it SET, nested twice with no secrets line EMPTY, nested twice with inherit at the outer call SET. This supersedes the reading recorded in iss-2608231912566984, which concluded that a called workflow's job cannot resolve environment secrets even when it declares the environment. That is false: it cannot resolve them without inherit at every level above it, which is a different defect with a one-line fix.
the release chain runs with an empty secrets context, because auto-release.yml passes none to release.yml. A called workflow's secrets context is ONLY what its caller passes. A job inside one that declares environment: gets the environment APPLIED — GitHub creates a deployment record for it — and still resolves none of that environment's secrets unless inherit unlocked the context first. release.yml has carried 'secrets: inherit' on its call to site.yml since v0.6.3; auto-release.yml's call to release.yml carried no secrets line at all, so the chain ran empty from the top and the production deploy failed on a credential that was never conveyed, on v0.6.2, v0.6.3 and v0.6.5. NOT v0.6.4: that release's render failed on an unfenced code block in a record and its deploy was SKIPPED, so it never reached the credential at all (run 32765800591; the iss-2608241845109280 defect). Verified from the release runs rather than assumed — v0.6.2 run 32657507210, v0.6.3 run 32674659520 and v0.6.5 run 32777924919 each show render success and deploy failure. Measured on a canary environment secret through the same two-level shape: a top-level job declaring the environment saw it SET, nested twice with no secrets line EMPTY, nested twice with inherit at the outer call SET. This supersedes the reading recorded in iss-2608231912566984, which concluded that a called workflow's job cannot resolve environment secrets even when it declares the environment. That is false: it cannot resolve them without inherit at every level above it, which is a different defect with a one-line fix.
Frontmatter
| id | iss-2608250536214009 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | major |
.abcd/work/issues/resolved/iss-2608250536214009-the-release-chain-runs-with-an-empty.md
open on GitHub ↗ · commit history ↗
mentions2
- iss-2608231912566984The v0.6.2 release published its binaries, then failed on its final job, and
- iss-2608241845109280abcd site build refuses a committed record, so the site render fails on main and nothing catches it before CI. .abcd/work/issues/resolved/iss-2608241347321757-...md:52 carries a four-space indented code block, and the renderer supports a fixed subset only: 'unsupported markdown construct: indented code block: fence code with backticks so it renders as a copyable command — the site renders a fixed subset and never passes text through unrendered'. The binary is behaving as designed; the record is non-conforming. It reached main because the site-screenshots workflow is path-filtered and the ci changes classifier stands jobs down for a pull request confined to .abcd/, so PR 489 never ran a site build, and the failure only surfaced on the first later PR touching a watched path (the v0.6.4 release PR 497). Two gaps, not one: the record's markdown is wrong, and record-lint does not check records against the renderer's supported subset even though every record under .abcd/work/issues/ is site-rendered. The second is the detector; the first is its acceptance corpus. Note screenshots is not a required status check, so this never blocked a merge.