FOS Release Workflows

FOGProject/fos — the Buildroot/kernel build repo covered in Fog Release — publishes its kernels and inits through three GitHub Actions workflows rather than the dev-branch → stable PR pipeline described in Stable Release Workflow. FOS has no dev-branch; every workflow here builds directly from whatever ref is checked out (normally master) and publishes straight to a tagged GitHub release.

• create_experimental_release.yml — on-demand, partial-build, prerelease. This is the workflow that actually gets used, including as the basis for the “official” release (see below).
• create_release.yml — named “Create Latest/Official Release”, designed as the full-build/official path, but it has never once been run (verified via the Actions API).
• make_usb.yml — intended to react to any published release and attach a bootable USB image, but has fired exactly once in the repo’s history, and that run failed.

Experimental Release

Triggered by hand (workflow_dispatch) with six boolean inputs — init and kernel, each for arm64/x64/x86 — so a maintainer can build just the piece under test (e.g. only the arm64 kernel after a driver change) instead of everything. input_checks fails the run if every input is left unchecked.

Only the selected build_kernel_*/build_initrd_* jobs run; the init jobs additionally restore a Buildroot download cache and an arch-specific ccache (keyed on build.sh’s hash and the run ID) to keep iteration fast. The final release job runs once every requested build job has finished, gated on !contains(needs.*.result, 'failure') && !contains(needs.*.result, 'cancelled') — a job that was never requested is neither failed nor cancelled, so skipping components doesn’t block the release.

The release it publishes is deliberately marked as not the “real” one:

• Tag: EXP_<UTC timestamp> (e.g. EXP_20260730-141502).
• Name: Experimental release from <UTC date/time>.
• prerelease: true, and the body is prefixed with an explicit backup warning.

This is the mechanism for getting a build in front of the community — testers install it manually — without it ever being mistaken for, or picked up by, tooling that looks for the latest non-prerelease/official release.

Create Latest/Official Release

The workflow actually named “Create Latest/Official Release” (create_release.yml) is built to always build all six kernel/init combinations — there is no per-component selection here — and only proceed to release if every one of those six jobs succeeds (plain needs:, no always() override, unlike the experimental workflow).

Two workflow_dispatch inputs are designed to decide what kind of release comes out:

is_official_release	official_fog_version	Result
unchecked	(must be blank)	Rolling release, tag <YYYYMMDD>, name Latest from <date>
checked	(required)	Official release, tag and name both the given version, name FOG {version} kernels and inits

input_checks enforces that pairing (version filled in iff the checkbox is set) before anything builds.

In practice, this workflow has never been run. Checking its GitHub Actions history directly (gh api repos/FOGProject/fos/actions/workflows/49199525/runs) shows "total_count": 0 — zero runs, ever, since it was added in February 2023. Every “Latest from …”/official-looking release actually published (see below) was produced a different way. Treat this workflow as designed-but-unused rather than as the real release path, and see the runner-image note at the end of this page before ever dispatching it for real.

How a release actually gets made official

The rolling “Latest from …” release name is called out in create_release.yml’s own comments as load-bearing — FOG’s Kernel Update page parses that exact release-name format — but the release that actually carries that meaning (the repo’s newest non-prerelease release) is produced by hand, by editing an Experimental Release’s output in place rather than by dispatching the dedicated workflow:

1. Dispatch Experimental Release as usual (all six components, or just the ones under test). It builds and auto-publishes its normal EXP_<UTC timestamp> prerelease, with all six kernel/init assets and their .sha256 files attached.
2. Once that build is confirmed good, edit that same release in place: change its tag to the plain rolling-release form (e.g. EXP_20260726-203912 → 20260730), rename the title (e.g. Release 20260730), and clear the “Set as a pre-release” checkbox. No files are re-uploaded — the six assets that experimental run already built and attached become the official release’s assets untouched.

This was confirmed directly from a real example: the 20260730 release (published 2026-07-26) has author: github-actions[bot] and a created_at that matches — to the second — the commit date of the master HEAD that an Experimental Release run (dispatched by a maintainer, run:30216684381) built from that same day; the release object is the bot-created prerelease from that run, edited afterward. GitHub’s release created_at reflects the tagged commit’s date rather than the API-call time, which is what makes this identifiable after the fact.

Editing the release like this only works cleanly the same day (or soon after) the experimental build finished: buildFilesystem() in build.sh stamps initversion into funcs.sh with the build’s own date (export initversion=$(date +%Y%m%d)), so retagging a much older experimental release as today’s “Latest” would ship an init whose embedded version string no longer matches the release date.

There is nothing to separately clean up — the experimental prerelease doesn’t keep existing under its old EXP_* tag once retagged; it becomes the official release object.

USB image attachment (currently not working)

make_usb.yml is written to listen for release: published, intending to build a bootable USB image from the release’s own assets (create-usb-image.sh against https://github.com/<repo>/releases/download/<tag>) and attach fos-usb.img back onto that same release. In practice this does not happen:

• It has fired exactly once in the repo’s entire history (2026-07-05), and that run failed.
• It does not fire for a release that’s promoted by editing an existing prerelease (the method above) — GitHub only sends the published action when a release is first published, not when a prerelease is later flipped to a full release, so the retag-in-place method described above never triggers it.
• Confirmed on the live 20260730 release: its only assets are the six kernel/init files and their checksums — no fos-usb.img.

So no FOS release currently ships an automatically-attached USB image; a USB image today would have to be built and attached by hand with create-usb-image.sh if one is needed.

If you do want to dispatch Create Latest/Official Release for real

Since it’s never run, nothing here is proven — this is a static read of the YAML, not a live result:

• No structural blockers found: repo-level default_workflow_permissions is write, so the implicit GITHUB_TOKEN can create a release with no explicit permissions: block, same as the (working) Experimental Release workflow. The kernel/Buildroot-version extraction and input-pairing validation are byte-identical to logic Experimental Release already runs successfully.
• It runs on ubuntu-22.04, which GitHub began deprecating on 2026-09-17 (full removal 2027-04-17) — jobs will start being intermittently failed during that window. Experimental Release was already moved to ubuntu-24.04 in the same commit that added it; this workflow was not.
• Its pinned action versions are two majors behind Experimental Release’s (actions/checkout@v4 vs @v6, upload/download-artifact@v4 vs @v7/@v8, softprops/action-gh-release@v2 vs @v3) — nothing currently broken, just a sign it hasn’t been touched since 2024-04-03.
• Unlike Experimental Release, its filesystem-build jobs have no Buildroot download/ccache caching, so a real run does a fully cold build for all three architectures — expect it to run considerably longer and be more exposed to network flakiness than the experimental builds you’ve actually been running.

Related

• Fog Release — the manual kernel/Buildroot/iPXE version-bump process that normally precedes a FOS release; that page’s “FOS kernel” and “FOS init” sections describe updating configs/kernel*.config/ configs/fs*.config, which is what these workflows then build and publish.
• Stable Release Workflow — the analogous promotion pipeline for fogproject itself. Unlike FOS, that repo promotes through a dev-branch → stable PR gated on install-validation tests; FOS has no equivalent branch model or automated test gate — promotion here is the manual dispatch described above, with community testing of the experimental prerelease standing in for automated validation.