Releases publish no installable package, only GitHub's source zip #14

Problem / context

The distribution model today is documented in macarchy-touchbar/.github/workflows/release-please.yml: "there is no publish job on purpose: this repository is installed straight from its git checkout (install.sh symlinks bin/… into ~/.local/bin), so the tag IS the artifact." That was a deliberate choice and it is what the request now overturns — reasonably, because "the tag is the artifact" only serves someone who already has the repo cloned.

omarchy-aikit/PKGBUILD is the existing precedent, and it is a -git package: pkgname=aikit-git, source=(git+https://…), a pkgver() that runs git describe. It builds HEAD, not a release. Useful as a shape to copy — its package() mirrors install.sh file by file, which is exactly the mapping each repo needs — but its versioning is the opposite of what this issue wants.

No ADRs in this repo (docs/adr/ absent; the profile records none), so nothing to check the approach against.

Approaches

A. Attach a .tar.gz of the tree to each release. Nearly free. Also nearly worthless: GitHub already attaches the source archive, so this adds a second copy of the same bytes under a different name. Rejected — it satisfies the letter of "produce an artifact" and none of its point.

B. Publish to the AUR. The idiomatic Arch channel, and it would make paru -S macarchy-touchbar work. But it is a different distribution channel, not a release asset: the AUR hosts a PKGBUILD, not a built package, and the request is specifically that a release carry something. It also adds an out-of-band credential and a second place versions can drift. Worth doing later; it does not answer this.

C. Build a .pkg.tar.zst in CI on tag, attach it to the release. (recommended) The artifact is installable with pacman -U, it is versioned by the tag that produced it, and it lives exactly where the request says it is missing. Proven above on real hardware.

Recommendation

C, rolled out in three slices rather than nine repos at once — one repo proven end to end, then the mechanical repeat, then the one repo that is genuinely different because it compiles.

B is explicitly deferred, not rejected: once C exists, an AUR PKGBUILD that points at the release tarball is a small follow-on, and it is the right second step. It is out of scope here.

Goal

Every release of a code-bearing macarchy repo carries a .pkg.tar.zst built from that tag, installable with pacman -U.

Scope

The five repos whose install.sh installs executables, plus the one that compiles:

Non-goals

• apple-glass / apple-glass-light — themes, not programs. Where an Omarchy theme belongs system-wide is a separate question this issue does not answer.
• macarchy-install — it is the bootstrap you run before you have anything; packaging it inverts its own model.
• AUR publication. The right second step, deliberately out of scope (brainstorm B).
• Changing what install.sh does. The package is an additional channel; the git-checkout install keeps working.

Design

flowchart LR
    A[release-please merges<br/>the release PR] --> B[tag vX.Y.Z + GitHub Release]
    B --> C{arch}
    C -->|any| D[archlinux:base-devel<br/>on ubuntu-latest]
    C -->|aarch64| E[Arch ARM container<br/>on ubuntu-24.04-arm]
    D --> F[makepkg --nodeps]
    E --> F
    F --> G[gh release upload<br/>glob the built file]

The job triggers on the Release being published, so it runs exactly once per version and cannot fire on a branch. makepkg runs as a non-root user (it refuses to run as root), builds with --nodeps (the container has no aarch64 dependency tree and the package's depends are a runtime contract, not a build one), and the upload globs *.pkg.tar.* rather than naming an extension.

Each repo's package() mirrors its own install.sh file for file — that mapping, not the workflow, is the per-repo work.

Edge cases

• A file install.sh fetches at runtime — macarchy-touchbar curls the Material Symbols font from master at install time, unpinned. In a PKGBUILD it belongs in source=() with a real sha256sum, which is strictly better than what happens today.
• A release that predates the workflow gets no asset. Acceptable; the next one does.
• A re-run of the job must not fail on an asset that already exists (gh release upload --clobber).
• makepkg as root — refuses. The container step needs a build user.

Assumptions

• The archlinux:base-devel image is x86_64-only, which is fine for arch=('any') packages: an any package is architecture-independent by construction. Verified only by reasoning, not by a build — the first slice proves it in CI or discovers otherwise.
• An aarch64 Arch container is available for the aquarium slice. Unverified; that slice's first task is to establish it.

Acceptance criteria

1. A tagged release of macarchy-touchbar carries exactly one *.pkg.tar.* asset, and gh release view lists it.
2. That asset installs with pacman -U on the target machine and puts macarchy-touchbar on PATH.
3. The workflow runs on release publication only — never on a push or a PR.
4. Re-running the workflow on the same release replaces the asset instead of failing.
5. apple-glass, apple-glass-light and macarchy-install still publish releases with no package, and nothing in their workflows changed.

Testing decisions

Seams under test: the built package's file list (tar -tf), and the release's asset list from gh release view --json assets. Both are observable without reading the workflow.
Prior art: macarchy-install/tests/clean-machine.sh — the existing pattern of proving an install by observing the result rather than the script.
A good test here: a tar -tf assertion that the package contains the same paths install.sh installs, so the two channels cannot drift apart silently.

Out of scope

• AUR publication, and any signing of the produced packages.
• A repository (pacman remote) hosting these packages — pacman -U on a downloaded file is the target.