Skip to content

release.yml: one script from a built output/ to a verified dist/ - #169

Merged
mcfbytes merged 6 commits into
feat/vanilla-buildroot-defconfigsfrom
feat/vanilla-buildroot-release
Sep 12, 2026
Merged

mcfbytes merged 6 commits into
feat/vanilla-buildroot-defconfigsfrom
feat/vanilla-buildroot-release

Conversation

@mcfbytes

Copy link
Copy Markdown
Owner

What this is

The release-workflow extraction from the CI simplification analysis, stacked on #167 (which is stacked on #166). Merge in order; each re-targets automatically.

scripts/mk-release.sh now owns everything between make and the sdcard image: the /MiSTer.version contract check, asset staging, the pinned stock archive (fetch, verify, extract, uboot re-verify), release_YYYYMMDD.7z assembly, the ARM-7za round trip under qemu-arm, the member-list check, and SHA256SUMS. It runs at a terminal with the STOCK_* pins exported, which the old inline steps could not.

  • release.yml: 1,110 → ~560 lines; the build job 27 → 9 steps; publish checks a fixed asset list plus sha256sum -c; dependency-graph extracts the one manifest. The STOCK_* pins, the azcopy job and the release-notes prose are carried over verbatim.
  • Proven locally end to end against the worktree build: release_20260904.7z 84,632,824 bytes, every verification step green, dist/ complete and checksummed.

Also in this branch's parent (#167), landed today: the build action reduced to one path (545 → 213 lines, two inputs), the retired-name pass across 33 live docs, docs/ci.md "The pipeline today" at the top with the old narrative kept under a historical heading, and the removal of two caller-less scripts.

🤖 Generated with Claude Code

https://claude.ai/code/session_01V21CRKVv5f66XFNbcrteMD

mcfbytes and others added 5 commits September 11, 2026 15:38
….yml 1,110 -> ~560 lines)

scripts/mk-release.sh owns everything release.yml's build job used to do
inline between `make` and the sdcard image: read /MiSTer.version back out
of linux.img and check the Downloader contract, stage the image assets and
the single legal-info bundle, fetch + verify + extract the pinned stock
archive (scripts/verify-stock-payload.sh, unchanged), assemble files/linux
with our linux.img/zImage_dtb/7za, pack release_YYYYMMDD.7z, round-trip it
under the pinned ARM 7za via qemu-arm, re-verify uboot.img/updateboot and
the member list, and write SHA256SUMS. It runs at a terminal with the
STOCK_* pins in the environment; proven locally against the worktree build
(release_20260904.7z, 84,632,824 B, every check green).

release.yml's build job goes from 27 steps to 9 (checkout, derive version,
build, verify-image, mk-release.sh, sdcard, summary, report, upload); the
two sdcard steps become one with SDCARD_CORES from the dispatch input; the
publish job checks a fixed asset list and `sha256sum -c SHA256SUMS` instead
of discovering kernel variants; the dependency-graph job extracts the one
manifest. The STOCK_* pin block, the build-azcopy job and the release-notes
prose are carried over verbatim. docs/ci.md's release row names the script.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V21CRKVv5f66XFNbcrteMD
…s' patch 0031

The rig, still on an RT 7.2.3 kernel built 2026-09-05 (before PR #152's
7.x re-anchor of the exFAT symlink patch shipped there), Oopsed on the
first symlink update_all.sh's Arcade Organizer created on /media/fat:
PC 0x0 from page_symlink() via exfat_symlink() -- the NULL write_begin
that the DE25's aarch64 QEMU leg had found on 2026-09-06. With
CONFIG_PANIC_ON_OOPS=y and panic=15 the board rebooted 17 s later.

Nothing executed that patch as 32-bit ARM: the DE10 QEMU leg builds at
the shipped 6.18 pin with the shared (page_symlink) form, and the only
runs of the 7.x rewrite were aarch64. `--kernel rt` (de10nano only)
builds the same multi_v7 test kernel at BR2_PACKAGE_LINUX_RT_VERSION with
linux-patches-beta/0031 and its own work/test-initramfs-rt* caches.
ci-tests.sh runs its three exfat-driver cases after the DE10 leg.

Verified locally at 7.2.4: symlink, exfat, fsck-request pass; the 6.18
form of the patch applied to the same 7.2.4 source reproduces the rig's
Oops in QEMU (PC is at 0x0, LR is at page_symlink), so the leg catches
the bug it exists for. The shipped 6.18.50 leg still passes symlink.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V21CRKVv5f66XFNbcrteMD
test-initramfs: --kernel rt, the 32-bit QEMU leg for the RT series' exFAT symlink patch
@mcfbytes
mcfbytes merged commit d87a284 into feat/vanilla-buildroot-defconfigs Sep 12, 2026
3 checks passed
@mcfbytes
mcfbytes deleted the feat/vanilla-buildroot-release branch September 12, 2026 00:38
mcfbytes added a commit that referenced this pull request Sep 16, 2026
release.yml: one script from a built output/ to a verified dist/
mcfbytes added a commit that referenced this pull request Sep 16, 2026
`scripts/mk-release.sh` stages into `release-work/` (mk-release.sh:36). Three
catch-all commits during the vanilla-Buildroot release work (PR #169) swept
that scratch tree and two tee'd run logs into git before .gitignore knew about
them:

  727b4d5  release-work/ -- 40 files, 22 MiB of stock 7za/zImage_dtb blobs,
           riding along on a one-line shellcheck fix
  850fea1  mk-release.log -- the very commit that added `release-work/` to
           .gitignore, which cannot untrack what is already tracked
  d331356  sdk.log

`*.7z` was already ignored, which is why only `stock_release.7z.verified` came
along and not the 100 MiB archive beside it. Nothing referenced the committed
copies: release.yml:116 copies the `release-work/stock_release.7z` that
mk-release.sh regenerates in the runner's own workspace.

Those three paths are removed from history with git-filter-repo. The rewrite is
scoped to 727b4d5^..master, so every commit from 2026-09-11 onward has a new
hash while everything older keeps its hash and its signature. `*.log` is added
here so a tee'd run log at the repo root cannot repeat this; `release-work/`
is already covered.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant