shadow-test
3c8296843f
Publishing to the AUR needs a maintainer AUR account and its SSH key registered as a secret here, neither of which exists yet. Rather than leave the workflow permanently failing at that last step, it now stops short of AUR and instead uploads the built .pkg.tar.zst to the same GitHub release it built from, as a plain downloadable asset (`pacman -U` to install). The AUR-push step is still in this file's git history if that setup happens later. Renamed publish-aur-package.yml -> publish-arch-package.yml to match. The render/validate steps are unchanged; new here is capturing the exact built package filename from inside the build container (makepkg is the only thing that actually knows it) and an upload step that follows the same create-or-reuse-release, strip-upload_url, POST-octet-stream pattern build-app.yml and backfill-releases.yml already use for GitHub assets, plus a delete-existing-asset-first step so a re-dispatch for an already-packaged version replaces rather than 422s. Verified with a real Docker run end to end: rendered a real PKGBUILD, built a real (synthetic) .deb through makepkg + namcap in an archlinux container, confirmed the container exits 0, and confirmed the exact package filename it captures (triple-c-bin-<version>-1-x86_64.pkg.tar.zst) round-trips out via docker cp intact.
2.7 KiB
Arch / CachyOS package
PKGBUILD here is the triple-c-bin package's template — see triple-c#34
(the "I would like to also have an Arch/CachyOS native version" part of it).
It's written to AUR conventions (and may go there eventually — see
"Publishing" below) but isn't published to the AUR yet.
Why "-bin"
It repackages the same .deb build-app.yml already produces, rather than
building from source. That means makepkg never needs a Rust toolchain,
Node, or the dozen -dev packages CLAUDE.md lists for building Triple-C
itself — and a user gets exactly the binary the project ships and tests,
built on Ubuntu 24.04 in CI. Verified end to end against a real release
(v0.4.14): downloaded the actual .deb, confirmed every depends entry
against a real ldd of the actual binary (two packages that looked right
from Tauri's own docs — pango, libayatana-appindicator — turned out not
to be real dependencies of this binary and were dropped), and ran a real
makepkg/namcap/pacman -U cycle rather than guessing at the shape.
Publishing
.gitea/workflows/publish-arch-package.yml does the actual work: given a
version (or "latest" if none is given), it finds that release's real Linux
asset on GitHub, downloads it, computes real checksums, renders this
template into a version-specific PKGBUILD, validates it with makepkg and
namcap inside a real Arch container, and attaches the resulting
.pkg.tar.zst to that same GitHub release as a downloadable asset —
installable by hand with sudo pacman -U.
It is workflow_dispatch-only, deliberately — see the workflow file's own
header comment for why an automatic trigger isn't safe here (the same reason
sync-release.yml didn't work and was removed in triple-c#32).
Not on the AUR yet. Publishing there would need a maintainer AUR account and its SSH key added as a secret on this repo — both manual, one-time steps on https://aur.archlinux.org that only a maintainer can do. The workflow's git history still has the AUR-push step from before this was descoped, if that setup happens later and it's worth reinstating.
What's hand-maintained vs. generated
pkgver/pkgrel/source/sha256sums in this file are placeholders —
the workflow rewrites them for every real publish and never commits the
result back here, so don't read this file's pkgver as "the last published
version." Everything else (depends, pkgdesc, package()) is meant to be
edited by hand normally, the same as any other PKGBUILD.
A hand-edit made to the rendered PKGBUILD attached to a GitHub release is not this file. Every run renders fresh from this repo's template, so a packaging fix belongs here, not in a downloaded copy — the next dispatch for that version would just overwrite it anyway.