* Release: scripts/cut_release.py cuts a release from green main without a bump pull request
On 11 Nov 2026 the release of 14 apps took most of the day. A large part went to version-bump pull
requests that changed only version strings yet waited on the full CI of a pull request (1-2 h of
FreeBSD, sharded SonarCloud coverage), and to rerunning it. The script commits the bump on the
newest main commit whose CI passed, merges it into release (which starts release.yml), opens the
same bump for main as its own pull request, and with --publish publishes the draft once the run
passed and has assets. Tests cover the bump: workspace and path-dependency versions, only the
workspace's own Cargo.lock entries, CRLF files, the repository hook.
* cut_release: review fixes
- A trailing comment after the workspace version stays; the value alone is replaced.
- Cargo.lock: only the workspace members' entries (cargo metadata --no-deps) change, not a local
path dependency outside the workspace that shares the version.
- Cargo.lock is checked with a resolving cargo metadata --locked, on the bump, on release after
the merge and on the sync branch; --no-deps never compared it with path dependency versions.
- --publish refuses a draft with fewer assets than the last release (a skipped build job leaves
the run green), unless --allow-fewer-assets.
- The sync PR never moves main backwards: versions compare as numbers, and a main at or past the
release gets none.
- A failed auto-merge says so, with the PR to merge by hand.
- Arguments that reach git or gh are checked first (owner/name, version, commit hash, workflow,
title), so none can be read as an option. git, gh and cargo are required up front.
* Release: scripts/release_train.py releases many apps at once with cut_release.py
Every app in parallel, a log per app, and one summary line each (published, pushed, or stopped
and why); one app stopping doesn't stop the rest. Tested on figcraft and soundcraft with
--dry-run (both done in under a minute).
* tests: release_train options before -- in the test
* release_train: only owner/name repos and known cut_release.py options reach the subprocess
A new optional LINUX_SIGNING_KEY secret (an unprotected OpenPGP signing subkey, from the
release environment) signs each Linux format the way its tools check it:
- rpm: embedded signature (rpmsign), for `rpm -K` and dnf/zypper gpgcheck
- deb: embedded _gpgorigin member (debsigs) and a detached .asc
- Arch: <file>.sig, which pacman looks for
- AppImage, tar.gz, zsync: detached .asc
- Flatpak bundle: signed commit and embedded public key (flatpak-bundle.sh, via the
scaffold's new step 4), so `flatpak install` verifies it, plus a detached .asc
- Flatpak OCI image: a containers/image signature for ghcr.io/<repo>@<digest>, which Flatpak
checks from its signature lookaside; the flatpak job records the pushed manifest for it
- SHA256SUMS.txt.asc over every release asset, and release-signing-key.asc
The draft-release action signs before computing checksums (embedded signatures change the rpm
and deb files) and verifies every signature against the exported public key. The new
import-signing-key action is shared by the flatpak and release jobs and refuses a key that
needs a passphrase. Without the secret, releases are published unsigned with a warning.
- A prerelease bundle (a version with `-`, as resolve-version marks it) gets no --repo-url: the
OCI index serves only the latest stable release, so Flatpak would replace the prerelease
with that older build. The generated script clears OCI_REPO for such a version and passes
${OCI_REPO:+--repo-url="$OCI_REPO"}.
- --verify passes only with the exact URL, the prerelease guard and the option on the active
build-bundle command; a commented-out command never matches, nor is it edited.
- A script that already sets OCI_REPO or its own --repo-url fails the scaffold instead of being
reported ready or overwritten.
- The OCI export assertion matches the whole line (CodeRabbit).
scaffold-flatpak-oci.sh now also adds --repo-url=oci+https://getartcraft.com to each app's
.flatpak build-bundle command, and --verify reports it. A bundle installed with that URL gets an
origin remote that updates from the OCI index, which points Flatpak at GHCR. Installing such a
bundle over an existing bundle install rewrites the existing origin's URL in place, so existing
users switch over on their next bundle update without a reinstall.
FredApps
Dylan M. Taylor