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
54 lines
2.8 KiB
Markdown
54 lines
2.8 KiB
Markdown
# 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.
|