actions/checkout can't run in the build job: the Gitea runner executes JS actions via `docker exec node …` inside the job container, and gentoo/stage3 ships no node, so checkout died with `exec: "node": ... not found` (exit 127) in run 111. Revert the build job to the node-free curl+tar checkout (restore net-misc/curl, /var/db/repos/azy5030 paths) and document why. The lint job keeps actions/checkout — it has no container: and runs in the runner's default node-capable image, where plain checkout works on this SHA-1 repo (confirmed green in run 111's lint job). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018MsAYv5RhNLE54fPrviVgS
4.9 KiB
CLAUDE.md
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
What this is
A personal Gentoo ebuild repository (overlay), repo name azy5030, EAPI 8,
masters = gentoo, thin + unsigned Manifests (metadata/layout.conf). It packages
software not in the main ::gentoo tree. Currently one package:
dev-util/gitea-runner. Hosted on a self-hosted Gitea at git.azy.dev. (This repo
is a standard SHA-1 repo; the sibling homeserver repo is SHA-256, so workflow
snippets copied from it may carry a GIT_DEFAULT_HASH: sha256 checkout override
that this repo must not use.)
The vendored-build model (the core design)
dev-util/gitea-runner is a go-module ebuild built offline from upstream
gitea/runner source. Gentoo's build sandbox has no network, so Go modules cannot be
fetched at build time. Instead they are vendored ahead of time:
- The upstream source archive is
SRC_URI'd from gitea.com's/api/v1/.../archiveendpoint (a plaingit clone/go getis never used). - A vendor tarball (
${P}-vendor.tar.xz, the result ofgo mod vendor, packed deterministically) is uploaded as a release asset on this repo and is the secondSRC_URI.S="${WORKDIR}/runner". dev-util/gitea-runner/Manifestpins BLAKE2B/SHA512 of both tarballs.emergeverifies against the Manifest, then compiles offline fromvendor/.
Consequences when editing the ebuild:
LICENSEmust cover every vendored module's license, not just upstream's MIT. The bump PR checklist suggestsgo-licenses report ./...to confirm.BDEPENDGo version tracks upstream'sgo.modgodirective.- The version string is injected via ldflags into
gitea.com/gitea/runner/internal/pkg/ver.version; CI assertsgitea-runner --versionechoesv${PV}. If upstream moves that symbol path, the build "succeeds" but reports the wrong version.
Bumping to a new upstream version
This is automated by scripts/bump-version.sh (run daily by bump.yaml, or
workflow_dispatch). To do it manually you must reproduce its steps, because a version
bump is never just renaming the ebuild — the vendor tarball must be regenerated and
re-uploaded as a release asset, or the build will fail Manifest verification. The script:
- Reads the latest
vX.Y.Zfrom upstreamreleases.rss; compares to the newest committed ebuild. Exits early if up to date or if abump/gitea-runner-<ver>branch already exists. - Downloads the source archive, runs
go mod vendor, packs a reproducible*-vendor.tar.xz(--sort=name --mtime='UTC 1970-01-01' --owner=0 --group=0). - Creates/reuses a release tagged
${PN}-${ver}-vendorand uploads the tarball asset. git mvs the ebuild to the new version, rewritesBDEPEND's Go version from upstreamgo.mod, and regenerates the Manifest withpkgdev manifest(after copying both distfiles into/var/cache/distfilesand wiring a temporaryrepos.conf).- Validates:
pkgcheck scan, thenemerge+gitea-runner --version | grep v${ver}. - Commits, pushes the branch, opens a PR against
master.
Requires a BUMP_TOKEN repo secret (scopes: repository read/write, write release) plus
a Gentoo env with go pkgdev git curl xz jq.
CI (.gitea/workflows/ci.yaml)
Runs on every push, two jobs. A lint job runs on the plain Docker-backend runner
(no container), checks out with actions/checkout, installs the linters, and runs
just lint (markdownlint/shellcheck/yamllint/actionlint). The build job has
needs: lint (lint is a gate) and runs inside a gentoo/stage3:amd64-openrc container:
emerge-webrsync to sync ::gentoo → configure portage (disables binpkg signature
verification so prebuilt deps like dev-lang/go are pulled, not compiled) → check out
via curl + tar, not actions/checkout into /var/db/repos/azy5030 → pkgcheck scan
→ emerge → assert gitea-runner --version matches the ebuild version.
The build job can't use actions/checkout (even though the lint job does): the Gitea
runner executes JS actions by docker exec node … inside the job container, and
gentoo/stage3 ships no node, so any JS action fails with exit 127. The lint job has no
container:, so it runs in the runner's default node-capable image and checkout works.
Conventions / gotchas
- YAML is linted by
.yamllint.yaml(relaxed: line-length and document-start disabled;truthy.check-keys: falsesoon:is allowed unquoted). metadata/md5-cache/is gitignored — portage regenerates it on sync, so never commit it (a stalegitea-runner-1.0.4file may linger on disk untracked).- The bump script and CI deliberately preserve the scheme of
GITHUB_SERVER_URL: on the self-hosted runner it is an internalhttp://endpoint. Don't hardcodehttps. - New packages must be added to
profiles/categories(currently justdev-util).