Cargo decides freshness by mtime, and the Gitea runner deletes the job
workspace after each run. So `actions/checkout` stamped every source file
with "now" and all 20 workspace crates recompiled regardless of what the
commit touched: measured on a JS-only commit, 20 of 722 rlibs rebuilt —
the ~700 third-party deps stayed cached, our own code never did. That,
not the size of skald-core, was the 4 minutes per architecture.
Restore mtimes from git history after checkout (needs the full history,
hence fetch-depth: 0 — cheap here, ~170 commits against a Gitea instance
on the same machine).
Also:
- nightly: CARGO_INCREMENTAL=1. Release builds have incremental off by
default, the worst case for a 51k-line crate. The nightly trades a
marginally less optimised binary for the rebuild time; release does not.
- nightly: concurrency with cancel-in-progress. The runner has capacity 1
and the nightly publishes to a fixed filename, so a queued build was
8 minutes spent on a tarball the next one overwrites.
- release: its own CARGO_TARGET_DIR. CARGO_INCREMENTAL is part of cargo's
profile fingerprint, so one shared cache between a workflow that sets it
and one that does not would have each invalidate the other's workspace
crates — reintroducing the very rebuild this removes.
- packaging steps derive --target-dir from $CARGO_TARGET_DIR instead of
repeating the path, so the two cannot drift.
A `systemctl --user` unit runs under the per-user manager, which systemd
starts at first login and stops when the user's last session ends — so
closing the SSH session that started Skald killed it, and it never came
up at boot. No crash and nothing in the journal: the whole cgroup is
simply torn down. Both installers now enable lingering after installing
the unit, and update.sh carries the same helper so an installation
predating this fix is healed by an ordinary update. A failure to enable
it only ever warns, with the manual command — it must not abort an
install.
Two things found on the way there:
update.sh matched `case "$OS" in Linux) ... Darwin)`, but $OS had already
been normalized to lowercase at the top of the file, so stop_service and
start_service were both silent no-ops. None of the ordering the file
documents at its head was executing: the tarball went over the running
binary (ETXTBSY, aborting the update mid-way) and the safety-net restart
in cleanup() was a no-op too, leaving the box down.
Neither workflow published install.sh / install-nightly.sh to the web
root, so the scripts served by builds.skaldagent.net were hand-copied and
drifting from the repo — an installer fix would reach every existing box
through update.sh but never a new one. Nightly publishes the nightly
installer, release publishes the release one, both with the same atomic
temp-and-rename the tarballs use.
Also on the unit: dropped `After=docker.service`, which a user manager
silently ignores rather than honouring advisorily, and moved
`Restart=on-failure` to `always` — run.sh exits 0 on any graceful
shutdown, including one nobody asked for, which on-failure reads as a
clean stop. That is also what absorbs the boot race against Docker now
that lingering makes us start at boot.
ci/package.sh requires --os (linux|darwin) but both nightly.yml and
release.yml were calling it without --os, causing the build to fail
with 'Missing required argument'. Add --os linux to all 4 package
steps (amd64 + arm64 in each workflow).
Daniele
dguiducci