🤖 Generated by the Agentic Engineer
Filed when the flag was born, per AGENTS.md → Shipping a new capability behind an opt-in flag
step 3 ("no permanent dead inputs").
Context
#858 added a guard to publish-app.yaml and publish-manifests.yaml that
refuses to run unless the caller pinned the workflow to a 40-character commit SHA — the property the
cluster's cosign trust rules depend on. It ships behind enable-caller-pin, default false, so
merging changes nothing for existing callers.
The flag is a release flag, not a kill switch: its whole purpose is to be removed.
Why it cannot simply default to true today
The guard runs only on a real publish. CI exercises both workflows with dry-run: true, which skips
the publish job entirely — so no CI job can ever execute the guard. The first real evidence comes
from an actual release. That is also why the flag exists rather than the change going straight in:
the first version of this guard read github.job_workflow_ref from the expression context, which is
always empty, and would have broken every publish while passing CI.
The rollout
Measured on 2026-08-02, every caller already satisfies the guard (7 of 7 pin by 40-hex SHA), so each
opt-in should be a no-op:
Then:
Acceptance criteria
Filed when the flag was born, per
AGENTS.md→ Shipping a new capability behind an opt-in flagstep 3 ("no permanent dead inputs").
Context
#858 added a guard to
publish-app.yamlandpublish-manifests.yamlthatrefuses to run unless the caller pinned the workflow to a 40-character commit SHA — the property the
cluster's cosign trust rules depend on. It ships behind
enable-caller-pin, defaultfalse, somerging changes nothing for existing callers.
The flag is a release flag, not a kill switch: its whole purpose is to be removed.
Why it cannot simply default to true today
The guard runs only on a real publish. CI exercises both workflows with
dry-run: true, which skipsthe
publishjob entirely — so no CI job can ever execute the guard. The first real evidence comesfrom an actual release. That is also why the flag exists rather than the change going straight in:
the first version of this guard read
github.job_workflow_reffrom the expression context, which isalways empty, and would have broken every publish while passing CI.
The rollout
Measured on 2026-08-02, every caller already satisfies the guard (7 of 7 pin by 40-hex SHA), so each
opt-in should be a no-op:
wedding-app—publish-appascoachingogvaner—publish-appgitops-tenant-template—publish-appdoggy-countdown—publish-app.github—publish-manifestsaws—publish-manifestsThen:
enable-caller-pin's default totrueonce at least one real release has published withit on.
if:guards, making the check unconditional..github/tests/test-publish-caller-pin.shin the same change,keeping the guard's own behavioural matrix.
Acceptance criteria
enable-caller-pininput remains in either workflow.(a 40-hex SHA accepted; branch, tag, PR-merge and near-miss refs rejected).
flips.