Fail the PR when a release pin names something that does not exist - #26
Merged
Conversation
fogproject GH-1030. Since GH-1029 the bundled plugins and the iPXE
binaries are fetched from pinned releases rather than committed, and
nothing checked that a pin points at anything real. A typo, or bumping
FOG_PLUGINS_VERSION/FOG_IPXE_VERSION before cutting the release, produces
a tree that lints, commits and merges cleanly and then dies at install
time -- on the person installing, not the person who made the mistake,
and a release could ship carrying it.
A tag existing is not enough and that is the arm worth having. Assets are
uploaded separately from the tag, so a release with none fails the install
exactly like a missing tag; the check reads the asset names.
Everything is derived from the tree, nothing from the branch name. This
workflow is shared by every fogproject branch and they do not carry the
same pins -- working-1.6 has both, dev-branch and stable have only the
iPXE one -- so a missing pin is skipped rather than failed. The Secure
Boot tarball is likewise conditioned on whether THIS branch's
lib/common/functions.sh actually fetches it. Deciding either from the
branch name means a new branch is silently unchecked, which is how the
vendor job below already handles the same problem.
The pin is read with the same awk lib/common/config.sh uses, so the check
and the fetcher cannot disagree about what the pin says.
No change needed in fogproject: the six-line stub there already calls this
workflow, so the job appears on every branch's PRs at once.
Verified against the real repositories, all three arms:
working-1.6 both pins, 4+2 assets found exit 0
dev-branch plugins pin absent -> skipped exit 0
v9.9.9-nope no such release exit 1
v2.0.0 tag does not exist exit 1
v2.0.0-fog.1 release EXISTS, predates the Secure
Boot asset -> named as missing exit 1
The job body is also kept runnable outside CI, because otherwise the only
way to watch it fail is to open a pull request with a bad pin:
scripts/background_scripts/check_fog_release_pins.sh, with FORCE_IPXE /
FORCE_PLUGINS to drive the failure paths.
Co-Authored-By: Claude <noreply@anthropic.com>
This was referenced Aug 19, 2026
darksidemilk
added a commit
that referenced
this pull request
Aug 20, 2026
#26 appended a `pins` job to fogproject-tests.yml while this branch appended a `schema` job, both immediately after `vendor`. Git matched the two jobs' shared scaffolding -- the job header, the blank line, `steps:`, and the identical `Check out the pull request` step -- and interleaved them into one broken job rather than reporting them as two separate additions. Purely additive on both sides, so both are kept whole: lines 1-235 are identical on both parents, `schema` follows from this branch and `pins` follows from main, each byte-identical to its source. Neither job's behaviour is touched. Resolved by reconstructing the tail from each parent rather than by editing the interleaved text, because the conflict was in the scaffolding the two jobs happen to share and hand-editing it invites silently attributing one job's steps to the other. All four jobs -- suite, vendor, schema, pins -- parse, as do the other thirteen workflows. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PqufBbuckux8kitJeW3uAK
darksidemilk
added a commit
that referenced
this pull request
Aug 20, 2026
Picks up #26's release-pins job by way of the parent branch. The conflict was the whole file, because this branch rewrites the trigger block and every checkout step while the parent added a job to the end -- so the two rewrote and extended the same regions. Resolved by taking the parent's file and re-applying this branch's change to it, rather than by editing the conflicted text. The change is mechanical -- add two workflow_call inputs, key the concurrency group on one of them, and point every checkout at both -- so replaying it is exact where hand-merging would be guesswork. That turns up something the merge is the first to expose: #26's `pins` job checks out bare, which is the very thing this branch exists to fix. Called from stable-releases.yml a bare checkout resolves to fog-workflows, so the pins job would have read fog-workflows for FOG_PLUGINS_VERSION and FOG_IPXE_VERSION, found neither, and skipped -- reporting a green pin check that never looked at fogproject. It now takes the same two inputs as the other three. Four checkouts covered, not three. All four jobs parse, and the inputs still default to empty so a pull request run is unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PqufBbuckux8kitJeW3uAK
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
2 participants
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 FOGProject/fogproject#1030.
Problem
FOG_PLUGINS_VERSIONandFOG_IPXE_VERSIONinpackages/web/lib/fog/system.class.phpname the releases the installer fetches. Nothing checked they point at anything real. A typo, or bumping a pin before cutting the release, produces a tree that lints, commits and merges cleanly and then fails at install time — on the person installing rather than the person who made the mistake.A tag existing is not enough. Release assets are uploaded separately from the tag, so a release with none fails the install in exactly the same way. The check reads asset names, not just the tag.
Approach
One new
pinsjob infogproject-tests.yml. No change needed infogproject— the six-line stub there already calls this workflow, so the job appears on every branch's PRs at once.Everything is derived from the tree, nothing from the branch name:
system.class.php, with the sameawklib/common/config.shuses, so the check and the fetcher cannot disagreelib/common/functions.shfetchesfog-ipxe-secureboot-That last row matters because this workflow is shared:
working-1.6carries both pins,dev-branchandstablecarry only the iPXE one. Deciding from the branch name would leave a new branch silently unchecked — the same reasoning thevendorjob already uses for the composer tree.Verification
Run against the real repositories, all three arms:
working-1.6— both pinsdev-branch— no plugins pinFOG_PLUGINS_VERSION=v9.9.9-nopeFOG_IPXE_VERSION=v2.0.0FOG_IPXE_VERSION=v2.0.0-fog.1The last one is the arm the issue calls out, driven by a real release rather than a mock.
The job body is kept runnable outside CI, because otherwise the only way to watch it fail is to open a PR with a bad pin:
scripts/background_scripts/check_fog_release_pins.sh, withFORCE_IPXE/FORCE_PLUGINSto drive the failure paths.Not a push trigger
Unchanged from the rest of this file —
pull_requestonly, no token beyond the caller's read-onlyGITHUB_TOKEN, no commit, no write. Nothing here can re-fire itself.🤖 Generated with Claude Code
https://claude.ai/code/session_01GN7hADN5QLzoxXWDA6xeUk