azy5030/azy5030-overlay

Public Access

Fork 0

Files

T

azy5030 98ed1c32ce

CI / lint (push) Successful in 21s

Details

CI / build (push) Failing after 4m25s

Details

ci: check out via actions/checkout (repo is SHA-1, not SHA-256)

Run 110's lint job failed at checkout ("couldn't find remote ref <sha>")
because GIT_DEFAULT_HASH: sha256 — copied from the SHA-256 homeserver repo —
made git init create a SHA-256 repo that can't resolve this repo's SHA-1
commits. This overlay is a plain SHA-1 repo, so checkout needs no hash override.

- lint job: drop the bogus GIT_DEFAULT_HASH: sha256 override.
- build job: replace the curl+tar checkout with actions/checkout into
  $GITHUB_WORKSPACE, registered with portage via repos.conf; pull dev-vcs/git
  in Configure portage (stage3 has no git, which checkout shells out to) and
  drop net-misc/curl (only the old checkout used it). QA scan / verify steps
  now reference $GITHUB_WORKSPACE.
- CLAUDE.md: correct the SHA-256 claim and rewrite the CI section for the
  two-job lint-gate + actions/checkout setup.

just lint passes; ci.yaml passes actionlint.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018MsAYv5RhNLE54fPrviVgS

2026-06-19 20:38:08 -05:00

4.6 KiB

Raw Blame History

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/.../archive endpoint (a plain git clone/go get is never used).
A vendor tarball (${P}-vendor.tar.xz, the result of go mod vendor, packed deterministically) is uploaded as a release asset on this repo and is the second SRC_URI. S="${WORKDIR}/runner".
dev-util/gitea-runner/Manifest pins BLAKE2B/SHA512 of both tarballs. emerge verifies against the Manifest, then compiles offline from vendor/.

Consequences when editing the ebuild:

LICENSE must cover every vendored module's license, not just upstream's MIT. The bump PR checklist suggests go-licenses report ./... to confirm.
BDEPEND Go version tracks upstream's go.mod go directive.
The version string is injected via ldflags into gitea.com/gitea/runner/internal/pkg/ver.version; CI asserts gitea-runner --version echoes v${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.Z from upstream releases.rss; compares to the newest committed ebuild. Exits early if up to date or if a bump/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}-vendor and uploads the tarball asset.
git mvs the ebuild to the new version, rewrites BDEPEND's Go version from upstream go.mod, and regenerates the Manifest with pkgdev manifest (after copying both distfiles into /var/cache/distfiles and wiring a temporary repos.conf).
Validates: pkgcheck scan, then emerge + 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; also pulls dev-vcs/git, which actions/checkout needs and stage3 lacks) → actions/checkout into $GITHUB_WORKSPACE, registered as the overlay via repos.conf → pkgcheck scan → emerge → assert gitea-runner --version matches the ebuild version.

Conventions / gotchas

YAML is linted by .yamllint.yaml (relaxed: line-length and document-start disabled; truthy.check-keys: false so on: is allowed unquoted).
metadata/md5-cache/ is gitignored — portage regenerates it on sync, so never commit it (a stale gitea-runner-1.0.4 file 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 internal http:// endpoint. Don't hardcode https.
New packages must be added to profiles/categories (currently just dev-util).

4.6 KiB Raw Blame History