shadow-testandClaude Sonnet 5
b3d07bda09
A review found the "Validate with makepkg and namcap" step's bind mount
(docker run -v "$PWD/rendered:/work") would very likely fail on Gitea's
own act_runner: a containerized job's $PWD isn't a path the daemon's host
can resolve, so the mount would silently attach an empty directory
instead of failing loudly — the same class of problem noted elsewhere for
this exact environment. Switched to docker create + docker cp (in and
back out) + docker start -a, the pattern already validated locally, which
works regardless of where the daemon actually lives.
Also found and fixed, most severe first:
- The namcap error gate (`grep -q "^[a-zA-Z0-9_-]*bin E:"`) only matched
one of namcap's two line shapes for reporting an error
("triple-c-bin E: ...") and missed the other ("PKGBUILD
(triple-c-bin) E: ...") entirely — confirmed by reproducing both against
a real namcap run. The PKGBUILD-level half of the safety net was dead.
Replaced with a plain `grep -q " E: "`, confirmed to match both real
shapes (and a split-package variant) and nothing else.
- package()'s `ar x "Triple-C_${pkgver}_amd64.deb"` named the asset
literally, defeating the whole point of the resolve step discovering
the real filename from the release instead of assuming a pattern — a
future Tauri bundler naming change would still break here with an
opaque error. Changed to `ar x ./*_amd64.deb`, which `source=()` already
guarantees matches exactly one file.
- `pacman -Sy` before installing packages is the canonical Arch partial-
upgrade footgun; changed to `pacman -Syu --noconfirm --needed`.
- `${{ inputs.version }}` was interpolated directly into a shell step
instead of routed through `env:`, unlike every other step in the file.
- `git push origin master` assumes the local branch name after cloning a
brand-new (not-yet-created) AUR repo's empty state is `master`, which
depends on the runner's own `init.defaultBranch` if the server sends no
symref. `git push origin HEAD:master` is unambiguous either way.
- The private key was written with a plain redirect then chmod'd after,
leaving a window where it's world-readable; now created at its final
mode first via `install -m 600 /dev/null`. Added `-o IdentitiesOnly=yes`
so a runner ssh-agent can't offer a different key first.
- Added GH_PAT auth to the api.github.com calls, matching every other
workflow in this repo, to avoid the unauthenticated 60/hour rate limit.
- Fixed two comments: the `options` comment credited `!debug` for
suppressing the empty debug-package directory, when it's actually
`!strip` doing that (verified in a real build); and documented in the
README that a hand-edit made directly in the AUR repo is silently
reverted by the next dispatch, since every run renders fresh from this
repo's template.
All of the above re-verified with the same real end-to-end methodology as
the original commit: real makepkg build, real namcap lint (clean), and
the exact updated docker create/cp/start sequence run against a live
container.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ
Arch / CachyOS package
PKGBUILD here is the AUR 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).
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-aur-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 pushes the result to AUR.
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).
Before it can push anything, an AUR account has to exist and the
triple-c-bin package has to have been created (or you added as a
co-maintainer) under it — both are one-time, manual steps on
https://aur.archlinux.org, since there's no API to automate creating an
account or a new package. Once that's done, add the account's SSH private
key as the AUR_SSH_PRIVATE_KEY secret on this repo. Until that secret
exists, the workflow fails at the "Push to AUR" step with a message saying
so, rather than silently doing nothing.
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 directly in the AUR repo is silently overwritten the
next time this workflow runs. Every run renders fresh from this
repo's template rather than starting from whatever AUR's copy currently
looks like, so a quick fix pushed straight to AUR (bumping pkgrel for a
packaging-only issue, say) survives only until the next dispatch. Make
the fix here instead.