- ci.yaml: filter the push trigger to branches. An unfiltered `push` also
fired for every tag ref, including the vendor-release tags the bump script
creates via the API.
- bump-version.sh: remove the pkgcheck/emerge/--version validation before
push. The branch push triggers CI, which runs the same checks and, unlike
the script's local copy, fetches the real release asset. The PR body now
asks for green CI instead of claiming the build passed in the bump job.
- vendor-tags.yaml: new workflow on pushes to master touching dev-util/**.
The vendor release is created before the bump commit exists (and PRs are
squash-merged), so its tag pointed at an arbitrary master commit. This
force-updates each vendor tag whose ebuild is in the tree to the master
commit that added that ebuild. Tags are only ever updated, never deleted,
since deleting a release's tag deletes the release and its assets.
- CLAUDE.md: document both changes.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
## Why
The daily **Bump** job (`runs/107` and every other scheduled run) does ~5–26 min
of work on every run before it ever checks whether a bump is needed — and on the
common no-op day it isn't. Timeline of a no-op run:
`docker pull stage3` → `emerge-webrsync` → **`emerge … dev-lang/go dev-util/pkgdev` (29 pkgs)** → `bump-version.sh` finds `already at latest` and exits in **1 second**.
`go`/`pkgdev`/`xz`/`jq` are only needed when a bump actually happens. Recent
no-op scheduled runs took 5m, 26m, 9m, 5m, 10m — all to do nothing.
Separately, the log on every emerge was flooded with binpkg GPG failures
(`unknown key`, `pubring.kbx: No such file`, `Try running getuto`). The
`sed 's/^verify-signature = true/.../'` matched nothing in the stage3 binhost
config, so the intended "disable binpkg signature verification" never took
effect (it worked anyway only because the failures are non-fatal).
## What
- **`bump.yaml`**: add a cheap `Check whether a bump is needed` step that compares
the newest upstream release (`releases.rss`) against the newest committed ebuild
(Gitea contents API) using only base-image `wget`, and gate `Sync ::gentoo`,
the toolchain install, and the bump step on its `needed` output. The gate only
short-circuits when **confident** (both versions parsed and current ≥ upstream);
on any doubt — failed fetch, unparseable version — it falls through to the full
run, where `bump-version.sh` remains the source of truth and re-checks.
- **`bump.yaml` + `ci.yaml`**: replace the no-op `sed` with `sed -i '/^verify-signature/d'`
+ append `verify-signature = false`, so the knob is actually set regardless of
the stage3 default contents.
## Notes / limits
- The job `container:` still pulls `gentoo/stage3` before the gate runs, so the
~3.5 min image pull on no-op days is unchanged; this saves the larger
webrsync + 29-package emerge. A follow-up could split the gate into a separate
container-less job to skip the pull too, but that depends on what the runner
maps `runs-on: ubuntu-latest` to, so it's left out here.
- Validated: `yamllint -c .yamllint.yaml` clean on both files; version-comparison
logic and the contents-API JSON parsing unit-tested locally (equal / upstream-newer /
current-ahead / parse-failure cases).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Reviewed-on: #4
Co-authored-by: Ali Zein Yousuf <azy5030@gmail.com>
Co-committed-by: Ali Zein Yousuf <azy5030@gmail.com>
A fresh gentoo/stage3 container has no /etc/portage/repos.conf directory, so
writing gentoo.conf failed. mkdir -p it first in both workflows and the bump
script.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Initial azy5030 overlay: scaffolding (eselect repository), the
dev-util/gitea-runner ebuild (go-module, vendored), CI build validation,
and a daily upstream-bump workflow.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
azy5030
