Reusing the linux job's binary (previous commit) doesn't work: it's
dynamically linked against ~100 libraries at absolute /nix/store
paths, including its own ELF interpreter, none of which exist inside
the Flatpak sandbox - confirmed locally via a real install+run
(execvp: No such file or directory). Reverted to building from source
inside flatpak-builder's sandbox via the rust-stable SDK extension,
same as the existing local `devbox run package` already does.
Also fixes two things needed for that in-sandbox build to work under
the forgejo-runner service (not an interactive session):
- appstreamcli (used by flatpak-builder to compose AppStream metadata)
wasn't on PATH - added as a devbox package (linux-only, like
gtk4/libadwaita) rather than a NixOS system package, keeping it
scoped to the project.
- rofiles-fuse's mount/unmount cycle fails under the service context
even though /dev/fuse itself is world-writable; --disable-rofiles-fuse
is flatpak-builder's own documented workaround for this.
Verified locally: full build, appstreamcli compose, bundle install,
and the installed binary actually executing inside the sandbox.
apfel is a laptop that's frequently asleep/offline; gating the release
on it (needs: [macos, linux, flatpak]) meant the whole release stalled
whenever it wasn't reachable. macos now appends its own asset directly
via the Forgejo API once it finishes, polling for the release that
linux+flatpak already created/overrode, instead of going through
actions/forgejo-release (which can only blind-create, not append to an
existing release).
Builds carrier-x86_64.flatpak from the linux job's already-built binary
rather than recompiling inside flatpak-builder's sandbox (which can't
see the shared cargo cache anyway, making an in-sandbox build pure
duplicate work). com.randogoth.carrier.release.json is a separate
manifest from the main one, which stays as-is for local
`devbox run package` dev-from-source builds.
actions/upload-artifact@v4 and download-artifact@v4 use GitHub's newer
Artifacts-v2 protocol, which Forgejo's server explicitly refuses
("not currently supported on GHES"). Forgejo maintains its own forks
(forgejo/upload-artifact@v5, forgejo/download-artifact@v7) with that
check disabled. Also drops archive: false, an input that fork doesn't
expose - the earlier binary rename already keeps filenames distinct
through the default zip/extract round-trip.
Builds macos-arm64 and linux-x86_64 release binaries in parallel and
uploads them as build artifacts; a single release job gated on both
then downloads and publishes them to one Forgejo release. Splitting it
this way avoids a real race in actions/forgejo-release itself: its
script always does a blind create-then-upload for the tag with no
merge path, so two parallel callers against the same tag either
hard-fail or stomp each other's uploaded assets.
