Builder Pool Naming: The (role, tier, replica) Coordinate#

Naming agent pools after the model they run today (kimi-N, deepseek-N, flash-N, lite-N) felt natural when each pool ran one model. It stopped feeling natural the third time a pool’s model churned — when the lite-tier swapped through qwen → gemma → gemini in six weeks and every rename cascaded through K8s manifests, secret names, MM bot accounts, Gitea identities, and helm values. The fix was to make pool names model-independent: builder-lite-0 runs whatever model the pool config says it runs today.

Jenkins Multibranch Silent Skip After Branch Recreate#

Push a branch named fix/foo. Trigger a multibranch scan. The scan log shows Checking branch fix/foo and immediately moves to the next branch with no verdict line. No job appears under the multibranch. No build fires. Other branches scan and build normally.

This is Jenkins’s branch source plugin silently skipping a branch because its internal cache treats the name as a duplicate of a previously-deleted entry. The cache survives plugin restarts, multibranch rescans, and kubectl rollout restart jenkins. The reliable recovery is to push the same commits under a different branch name — the cache has no entry for the new name and processes it cleanly.

Jenkins Multibranch with Gitea: Why Pull Request Builds Never Run#

A common, maddening symptom: your Jenkins organization folder (or multibranch pipeline) backed by Gitea builds the default branch fine, but pull request commits never build — the commit status stays pending forever (or never appears), so a branch-protection gate that requires a CI status can never be satisfied and the PR can never merge.

The pipeline is fine. The problem is branch/PR discovery configuration, and there are several layered traps. Here is how to diagnose and fix each.

A pull request has two state: APPROVED reviews from different reviewers. Branch protection requires required_approvals: 1. The merge attempt returns HTTP 405 — "Does not have enough approvals". The protection config looks correct, the reviews look correct, and the error message looks misleading. The actual root cause is hidden in a field most operators never check: official.

What official means#

Every Gitea review carries an official boolean. Branch protection’s required_approvals counts only reviews where official: true. A reviewer’s APPROVE only flips to official: true if they were a write-level repository collaborator at the moment the review was filed.

A self-hosted Gitea forge running on Kubernetes covers four operational concerns that the upstream chart leaves to the operator: identity hygiene for bots and humans, branch protection rendered from code rather than clickops, webhook wiring to CI, and a backup story that survives a cluster wipe. The companion article Gitea Collaborator Grants and Review Officiality covers the narrow operational gotcha of official=false reviews; this article is the broader runbook for running the forge well.

A single-node minikube cluster on Docker Desktop runs the entire control plane, kubelet, every PVC, every Secret, and the container image cache inside one VM whose disk is one file: ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw on macOS. When that file is lost or corrupted, every piece of cluster state goes with it in a single event. There is no “node failure vs storage failure” distinction to design around. Every backup strategy that assumes those are separable does not apply.