ci: assert the produced tag set on pull requests and write down the verification standard - #24
Merged
Merged
Conversation
Add a step after the metadata step that fails the job when the tag set produced by docker/metadata-action does not match the expected set for the current caddy_tag, so a change to the tag logic is caught in CI instead of relying on manual review. The check runs only when the pull_request event triggers a build and compares by set membership plus count, not by exact string or line order. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Add a Workflow Verification section to README.md that states what the pull request tag assertion, the pull request build with push: false, the local static checks, and the live scheduled run each cover, and what is not verified before a merge. Record the act ruling with its reason. Add the matching table of contents entry and a pointer line in CLAUDE.md outside the OpenWiki marker block. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The section claimed every scheduled run and every push to main does a real multi-arch publish and crane copy mirror. That is false: a push only forces a build when Dockerfile-cloudflare or .dockerignore changed, a scheduled run never forces one, and the decide step still gates a real publish behind detecting an upstream change either way. Rewrite both paragraphs to say what the decide step and the mirror step's condition actually guarantee, and drop the duplicated cron time in favor of pointing at "When Builds Run". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
README.md's Workflow Verification section now names the actionlint CI job from PR #23 and reframes the local static checks as a fast pre-review pass rather than the only gate. The run-record's stale-worktree finding now records what was observed and when, and that it resolved on its own via PR #23 once this branch was rebased onto main, instead of asserting a now-false current state. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #20.
Issue #20 asked whether this repository wants a local dry-run path for its build workflow, and listed three candidates. This branch answers all three.
actis rejected. Thedecidestep callscraneagainstcaddy:latestand the GitHub API, so a local run is not hermetic.actcannot reproduce the multi-arch push or thecrane copymirror, which is exactly the part no static check covers. What a local run would prove is already proven more cheaply by the static checks and by the new assertion, in the place that gates a merge. Against that, it costs a Docker-in-Docker setup in a repository with no other local toolchain.The pull request now asserts the tag list it produced. A new
Assert produced tag setstep runs on pull requests only, and only whendo_buildis true, comparing the tag setdocker/metadata-actionproduced against the set thedecidestep'scaddy_tagimplies. It compares by set membership plus a count rather than by string equality, so a change in how the action renders its output cannot fail the job on its own. It never runs onpush,scheduleorworkflow_dispatch, so it cannot fail a publishing build.The standard is written down.
README.mdgains a "Workflow Verification" section naming each layer: the static checks before review, actionlint and the tag assertion in CI, and the run onmainas the first real execution. It states plainly what is not verified before a merge, and records theactruling with its reason.CLAUDE.mdgains one pointer line to it.The run record and report are in
docs/assembly-line/2026-08-24-workflow-verification/.Two things worth a reviewer's attention. First,
do_buildis not always true on a pull request: the trigger's path filter evaluates the pushed commits' diff whileClassify local changesdiffs base to head, so a pull request whose later commit reverts an earlier change re-triggers the workflow with both change flags false. That is why the assertion step carries thedo_buildguard. Second, this branch was rebased onto the actionlint merge from #23, which landed while the work was in flight, and the README section names that layer.Generated by an assembly-line run with two inspectors per package.