Fix cross-platform red build: canonicalise line endings, refresh sortablejs pin - #5
Closed
roosch269 wants to merge 1 commit into
Closed
Conversation
…ablejs pin The release regression test compares the schema embedded in the committed release HTML byte-for-byte against dev/specification/guerrilla-ops-schema.xml. On a Windows checkout core.autocrlf converts the working copy to CRLF, so a locally built release embeds CRLF while the repo source is LF, and the test fails on every Linux runner (red since 2026-08-15, deploy and release skipped). Small changes close the observed divergence at the source: - build_release.py canonicalises line endings in both files it embeds by exact bytes: the QA schema and the favicon SVG. The embedded content no longer depends on how the source was checked out. This also covers an existing autocrlf worktree that upgrades to this commit, where git does not rewrite unchanged working-tree files and .gitattributes alone would not help. - runtime-regression.js normalises the schema the same way, so the byte-equality check passes on any platform while still catching a genuinely stale artifact. - .gitattributes pins the repo to LF as belt-and-braces hygiene. Verified under the tested toolchain: LF, CRLF-schema, CRLF-SVG-only (the upgrade path), and all-text-CRLF checkouts each produce byte-identical airgapped HTML, and all three regression suites pass in each. Also refreshes the sortablejs 1.15.6 pin. jsDelivr now serves the byte content of the npm tarball member (verified: registry dist.integrity matches the tarball, tarball member sha256 6d0a831f... matches the CDN response), so the previous pin was stale rather than the package compromised.
Andrew-Waring
approved these changes
Aug 16, 2026
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.
Fixes the build that has been red since Saturday afternoon (deploy and release skipped since then).
Cause. The release regression test compares the schema embedded in the committed release HTML byte for byte against
dev/specification/guerrilla-ops-schema.xml. On a Windows checkoutcore.autocrlfgives the working copy CRLF endings, so a locally built release embeds CRLF while the repo source is LF. Green locally, red on every Linux runner.Fix.
build_release.pynow canonicalises line endings in both files it embeds by exact bytes (the QA schema and the favicon SVG), so the output no longer depends on how the source was checked out. This also covers an existingautocrlfworktree upgrading to this commit, where git does not rewrite unchanged working-tree files and.gitattributesalone would not help. The regression test normalises the same way, and.gitattributespins the repo to LF as general hygiene.Verified. LF, CRLF-schema, CRLF-SVG-only (the upgrade path) and all-text-CRLF checkouts each produce byte-identical airgapped HTML, and all three suites pass in each. A side effect worth having: anyone can now rebuild
Guerrilla-Ops-Airgapped.htmland verify the hash against a published release, which seems valuable for the secure environments it is aimed at.Also: sortablejs pin refreshed. jsDelivr serves different bytes from the pinned hash and the build rightly refuses to run. Verified before changing anything: the npm registry's
dist.integritymatches the tarball, and the tarball member sha256 (6d0a831f...) matches the CDN response. The package is genuine; the pin was stale. (The hash gate itself works well. Mid-testing, the sheetjs CDN served a bad response and the build correctly refused it.)Artifacts rebuilt from the canonical source.