* 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
* release.yml: a dry-run input builds and checks without releasing
For a nightly run on main that finds release-only breakage before release day. On 11 Nov 2026
gridcraft's riscv64 build, materialcraft's private-repo FreeBSD jobs, wordcraft's Print job and
the riscv64 apt mirrors each surfaced only during the release, one fix PR and release run at a
time. With dry-run: no job enters the release environment (no signing secrets; the environment
admits only the release branch), the macOS job and the draft are skipped, and the Flatpak OCI
layouts are not pushed to GHCR or Docker Hub.
* tests: the Flatpak OCI push and the release environment also stay out of a dry run
* ci: use StepSecurity's maintained actions
Each third-party action that StepSecurity publishes a secure drop-in
replacement for now uses that replacement, pinned to a commit with its
version as a comment. Versions follow what we used: the newest
StepSecurity release in the same major, or the closest major they
publish. dtolnay/rust-toolchain refs that named a toolchain (stable,
nightly, 1.76) become the replacement's `toolchain` input.
* tests: find the FreeBSD VM, SonarCloud scan and install-action steps by their StepSecurity names
* sonarcloud: honour each repository's own sonar.cpd.exclusions
* sonarcloud: read sonar.cpd.exclusions with properties syntax and allow the ? wildcard
During the ubuntu.com outage, cloud-init's apt_configure module (once per
instance, at boot) spent two 10-second DNS timeouts looking for a mirror
and then wrote ubuntu.sources from its template, after the job had
started. On those VMs configure-apt-mirrors had already pointed the
sources at its list: apt-get update fetched every index for that list,
cloud-init put the image's mirror list back, and apt-get install found
no indexes for it, so no Ubuntu package had a candidate (materialcraft's
Flatpak x86_64 job, the FreeBSD tests job on 26.04). A repro on 12
runners failed on 8, every round, and a file watcher caught cloud-init's
write landing mid-update.
wait-for-cloud-init.sh runs `cloud-init status --wait` (at most 300 s,
never failing the job) before configure-apt-mirrors and
install-riscv64-cross's select-mirrors.sh touch anything.
The release builds' Linux riscv64 job read amd64 from archive and
security.ubuntu.com and riscv64 from ports.ubuntu.com only. With no
ubuntu.com name resolving on the runners, apt spent 3m20s on failed
lookups and then found no libc6-dev:riscv64, so every app's release
failed there.
select-mirrors.sh now chooses one pair of mirrors for both architectures:
Ubuntu's own, then dotsrc (it carries both trees), then kernel.org with
TU Chemnitz's ports. It takes the first pair whose amd64 and riscv64
InRelease files answer for every suite with the same Date (Ubuntu signs
one Release for archive and ports), so Multi-Arch: same packages still
match. The image's own Ubuntu sources are disabled in that job: they
only added a second, lagging snapshot and, during the outage, the stall.
The riscv64 job runs Harden-Runner in audit mode, so release.yml needs
no allowlist change.
Harden-Runner blocked apt's SRV lookups (_https._tcp.mirrors.edge.kernel.org,
_https._tcp.mirrors.dotsrc.org): the allow lists name the hosts, not their
SRV records. configure-apt-mirrors now sets Acquire::EnableSrvRecords false;
apt connects to the hosts directly either way.
The FreeBSD workflow's VM action apt-installs QEMU on the host, which failed
during the ubuntu.com outage (sudo exit 100) and reached packages.microsoft.com.
Run configure-apt-mirrors first and drop the image's Microsoft source, which
the job never installs from.
On 11 Nov 2026 no ubuntu.com name resolved on the runners for about
half an hour. The images' mirror list (azure.archive, archive and
security.ubuntu.com) sits entirely in that zone, so every retry spent
its five minutes on 20-second lookups of the same dead names and the
SonarCloud archive builds failed with "downloading the packages failed
3 times".
configure-apt-mirrors points the image's Ubuntu sources at
/etc/apt/craft-apt-mirrors.txt: the image's mirrors in the image's
order, then mirrors.edge.kernel.org and mirrors.dotsrc.org (arm:
mirrors.dotsrc.org and ftp.tu-chemnitz.de). Each mirror is checked
first, in parallel; those that do not serve this release's InRelease
move to the end. install-apt-packages runs it before every network
attempt, and the plain apt-get steps (Flatpak, release, packaging lint,
RPM signing, Linux deps, FreeBSD test) run it before apt-get update.
Block-mode Harden-Runner lists allow the new hosts.
* ci: harden workflows with credential isolation, template injection defenses, and dependabot cooldown
- Add persist-credentials: false across all actions/checkout invocations
- Eliminate template injection by mapping matrix and input variables to env: in freebsd.yml, release.yml, and sonarcloud.yml
- Add 7-day cooldown to dependabot.yml to protect against supply-chain compromise of recently published releases
- Update test suite to validate hardened environment mappings
* ci: allow static.crates.io and registry endpoints in gate and windows-arm64 runners
Bound archive and checksum download retries, including refused connections, while retaining HTTPS and SHA-256 validation. Report missing checksum entries using an exact archive filename lookup. Add nine real-curl regression tests for recovery, permanent failures, retry bounds and checksum validation.
Add allow-published (default false) to draft-release. When true, draft-release
permits uploading assets to an existing published release without failing or
attempting to convert it to a draft with --draft.
* release.yml: export each app's build variables from its env.sh, not a list
Eight release jobs set <APP>_VERSION, <APP>_BUILD_DATE and <APP>_BUILD_SHA for
every app by name (298 lines), and the FreeBSD VM step listed them all again,
so every new app meant editing this workflow. materialcraft and texturecraft
were never added: their packaging reads MATERIALCRAFT_* and TEXTURECRAFT_*,
so their release builds got no release version, date or commit, and a
dispatched run with a version override packaged them under Cargo.toml's.
actions/export-app-build-env reads the prefix the app's packaging/env.sh (or
packaging/common.sh) already declares in VERSION="${<PREFIX>_VERSION:-...}",
falling back to app-name in capitals, and writes the three variables to
GITHUB_ENV; its names output feeds the FreeBSD VM's envs. Each job runs it
right after checkout. On all 17 apps' env.sh it finds the prefix the old
list used.
Tests run the script on sample env.sh files and check release.yml sets no
app's variable by name, so the list can't come back.
* Export the build variables after the contributor snapshot, which must follow the checkout
test_contributor_refresh requires each build job to load the contributor snapshot directly after checkout, so the export step goes after it when a job has one. Also fix the line-break test passing a variable twice.
---------
Co-authored-by: nnaannoo <n4nosaur@gmail.com>
The writer and the checker share one normalization. A rewritten digest does not make an edit pass, an intact older copy warns only when main has moved on, and a source that cannot be read is reported as could not check.
Co-authored-by: Cursor <cursoragent@cursor.com>
Eight apps paste the same 25-line job into ci.yml, nix.yml or release.yml (ten
copies): Cargo.lock exists and is up to date, no .cargo/config(.toml)
replaces, patches or overrides a source, and every git dependency comes from
github.com/storytold. Apps' workflows are meant to only call workflows here.
actions/check-git-sources holds the check as a tested script, and
git-sources.yml runs it on a credential-less checkout, so an app swaps its
job for one `uses:` line and keeps `needs: git-sources`. It reports every
problem rather than the first, as GitHub error annotations, and treats
unreadable TOML as a failure. On all 18 apps' current Cargo.lock and Cargo
config it agrees with the inline copy.
Co-authored-by: Kristian Myram <kmy@oresundsbron.com>
The release job ran each app's packaging/linux/flatpak-oci.sh --push. Most
apps still carry the copy from before scripts/scaffold-flatpak-oci.sh learnt
to guard the stable tag, and it moves stable-<arch> on every push, so a
prerelease or a test run dispatched from any branch became what stable-<arch>
clients install. 15 of the 17 apps carry that copy.
Call the script without --push, which only builds the layout in every copy,
and push from the workflow: <version>-<arch> on every non-PR run, and
stable-<arch> only for a stable version built from the release branch, the
rule the scaffold template already uses. No app needs to change.
Co-authored-by: Kristian Myram <kmy@oresundsbron.com>
* Add the setup-windows-signing action: the shared Authenticode signing script
Every app carries its own packaging/windows/sign.ps1 and the copies have drifted: four lack the
Trusted Signing client SHA-256 pin. The action exports the maintained script, parameterized by
product name and URL, for package.ps1 to call; it rejects line breaks that could inject
environment variables, and refuses an unset product name. The script reads file names literally.
Tests run it against a stand-in signtool.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013fTnVxnXTv2MBW6uj2PPyU
* Test that an unset product name gets the clear message, not a null-method error
PowerShell echoes the failing source line, so the message alone passed on the old code too.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013fTnVxnXTv2MBW6uj2PPyU
* Refuse a non-x64 signtool for Azure Trusted Signing
The Azure branch loads the x64 Azure.CodeSigning.Dlib.dll, but SIGNTOOL or
PATH can name an x86 or ARM64 signtool.exe, which cannot load it. Read the
PE machine type of the chosen signtool and fail with a clear message before
downloading the client. A file that is not a PE image is left alone.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Kristian Myram <kmy@oresundsbron.com>
* Add shared macOS certificate import and Windows signing script actions
Every app carries its own packaging/macos/import-cert.sh and packaging/windows/sign.ps1, and the
copies have drifted: four apps lack the Trusted Signing client SHA-256 pin and eight still write the
signing certificate to a predictable temporary path.
- import-macos-certificate: the hardened import (private mktemp -d directory, keychain removed on
failure), self-contained, with identity/keychain outputs.
- setup-windows-signing: exports the shared sign.ps1, parameterized by product name and URL, for
package.ps1 to call; rejects line breaks that could inject environment variables.
- Tests run both scripts against stand-ins for security, openssl and signtool.
Existing callers are unchanged; apps adopt the actions one at a time.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Signing scripts: read file names literally, refuse an unset product name clearly
sign.ps1 resolved its file arguments with Resolve-Path, which treats [ and ] as wildcards, so a
file such as 'App [x64].msi' failed. setup-windows-signing called .Trim() on an unset product
name, a null-valued method call, instead of its own message. Tests for both.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013fTnVxnXTv2MBW6uj2PPyU
* Split the signing PR: keep only the macOS certificate import here
The Windows signing action moves to its own branch and PR. The tests, README text and bullet for
each action now live with that action, with separate README headings so the two PRs merge
independently.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013fTnVxnXTv2MBW6uj2PPyU
---------
Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
* Add changed-paths.yml: run a job only when its paths change or a label asks
* changed-paths: read paths NUL-separated, keep the reason on one line; README: what the checkout holds
Anyone can commit under an agent email, so a free-form Git name such as
"Private Person <noreply@anthropic.com>" became a published model title,
which the apps would ship in their About windows. Each provider now lists
the words a model title may use. A name with any other word credits the
agent's default model and repeats none of it; versions are bounded too.
Across the co-author trailers in the 13 apps' history, 18,099 keep their
model row and 7 unusual names now fall back to the default. Also pin that
the PR lookup reads the merge commit rather than the PR head.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
effectcraft's 4,000-commit history made 50-commit association queries time
out on GitHub, so batches are smaller and a failed batch is retried once.
GraphQL names bot openers without the [bot] suffix, which turned dependabot
into a person; only User accounts now count as PR openers.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
GitHub links agent trailers such as noreply@anthropic.com to the claude and
codex accounts, so they appeared as the top human contributors. Agents are now
recognized by exact Git email or GitHub account, never by name, and credited
only in the snapshot's models (About > Models), including commits an agent
authored itself. Bots are no longer listed as people. Model and version are
read from the agent's Git name, covering every provider the apps' history
uses.
Commits merged with a merge commit or rebase never equal a PR's merge commit,
so self-added names lost verification and unlinked commits lost their author.
GitHub's commit-to-PR association now supplies the opener of the one merged PR
containing the commit. An integration PR opened by a writer that carries the
person's own linked commit also verifies their entry.
Against the shipped snapshots of effectcraft, pdfcraft, photocraft and
lightcraft at their recorded heads, no person loses a row, a name or a commit.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The paths input is checked to stay inside the checkout, but its original
spelling was then passed to ast-grep where option parsing still applied, so
a checked file named like an option (--update-all, --follow) changed how the
scan ran. Pass "--" before the path list in both scan invocations.
The metainfo path comes from the release archive. A symlink to an endless
stream such as /dev/zero, or a FIFO, made sed read without bound. Refuse a
metainfo entry that is not a regular file resolving inside staging, read at
most 1 MiB of it once, and parse the summary and homepage from that prefix.
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
nnaannooandnnaannoo
Kristian Myram