release.yml fired on every push to main, so the trigger was "a PR was merged" and nothing else decided. That is a version per unit of *work* rather than per *shipment*: eight releases in twenty-two hours, v0.0.1 through v0.3.1, for one session -- each fanning out to four publishers on a runner with capacity 1, so roughly forty packaging jobs shipped three issues while ordinary PR CI queued behind them. pacman, Homebrew and Obtainium see every one. The push trigger is gone and workflow_dispatch, which was already there and already worked, is the whole mechanism. Nothing else had to change to batch releases, because semantic-release already reads every commit since the last tag: five fixes and two feats become one minor release with all seven in the notes. Release frequency was only ever how often this file fired. This is the rule index-artifact.yml states and is the other instance of: a job that mutates state which cannot be rebuilt in ten minutes is triggered deliberately, not by a push. A release here is a tag, a Gitea release, an Arch package, a Homebrew formula, a signed APK and desktop assets -- and an Android version going backwards costs the user their library. `dry_run` is what makes a manual trigger usable: the point of pulling a lever by hand is being able to look first, so the input runs semantic-release --dry-run -- the version and the notes, no tag, no release, no publishers. Anything but the literal string "true" releases for real, because a typo in a dispatch box must not silently turn a shipment into a green no-op. Two alternatives were considered and rejected, both recorded on the issue. A `beta` integration branch relocates the trigger rather than removing one: it needs a second protected branch carrying the same required checks, and it *adds* a full check + e2e run per batch on the very runner whose queue is the complaint. A schedule batches without anyone having to remember, but puts the decision back on a timer, which is the thing being removed. Closes #115
2.4 KiB
YellowJacket Arch package
This directory holds the PKGBUILD and desktop entry used to build the
Arch Linux package. CI builds it on every release tag (see
.gitea/workflows/arch-package.yml) and publishes it to the Gitea Arch
package registry, from which pacman can install it directly.
Tags come from .gitea/workflows/release.yml, which is run by hand — it
used to fire on every push to main, which meant a new package per
merged PR (issue #115). A prerelease tag (v0.4.0-beta.1) is skipped:
the workflow's trigger is v* and matches one.
Installing from the registry
The registry is public — no login required.
1. Import the registry signing key (one-time)
Gitea signs both the repo database and the packages with a per-instance GPG key. Import its public key and locally sign it so pacman will verify signatures:
curl -fSs "https://git.ljones.me/api/packages/yonlu/arch/repository.key" \
| sudo pacman-key --add -
sudo pacman-key --lsign-key C061B6267CF9D820
- Key ID:
C061B6267CF9D820— UID(Arch Registry), RSA 2048. - This is a public key; publishing it is expected. The private key stays on the Gitea server.
- The key is per-Gitea-instance, so you import it once regardless of how
many registries on
git.ljones.meyou use.
2. Add the repo to /etc/pacman.conf
Append to the end of the file:
[stable]
SigLevel = Required
Server = https://git.ljones.me/api/packages/yonlu/arch/stable/$arch
$archis a literal pacman variable (expands tox86_64); leave it as-is.[stable]matches theARCH_REPOvalue in the publish workflow.
3. Sync and install
sudo pacman -Sy yellowjacket
Alternative: skip signature verification
If you'd rather not import the key, set SigLevel = Never instead of
SigLevel = Required in the repo block above. Simpler, but you lose
tamper detection, and the signing-key path is only a one-time step — so
this is not recommended.
Notes
- Only the runtime package is published; the
-debugpackage makepkg produces (detached symbols) is skipped by the workflow. - Package versions come from
pkgver()in the PKGBUILD, derived from git (e.g.1.3.0.r173.g4ae5ffc-1), so every release tag yields a new version. - Repo priority: if another configured repo ever provides a package named
yellowjacket, the repo listed first inpacman.confwins. Force a source explicitly withsudo pacman -S stable/yellowjacket.