Skip to content

ci: route docker build jobs to self-hosted runner#89

Merged
Gumbees merged 2 commits into
developmentfrom
ci/self-hosted-runner
May 19, 2026
Merged

ci: route docker build jobs to self-hosted runner#89
Gumbees merged 2 commits into
developmentfrom
ci/self-hosted-runner

Conversation

@Gumbees

@Gumbees Gumbees commented May 12, 2026

Copy link
Copy Markdown
Collaborator

Summary

Routes heavy Docker buildx multi-arch jobs to the new self-hosted runner pool (label nate-wsl). Light orchestration jobs stay on GitHub-hosted.

Workflow Job Before After
build-pr.yml guard ubuntu-latest (unchanged)
build-pr.yml build-server ubuntu-latest self-hosted
build-pr.yml build-embedder ubuntu-latest self-hosted
build-pr.yml build-worker ubuntu-latest self-hosted
direct-push.yml guard ubuntu-latest (unchanged)
direct-push.yml build ubuntu-latest self-hosted
promote-on-merge.yml promote ubuntu-latest (unchanged — manifest retag only)
release.yml github-release-on-merge ubuntu-latest (unchanged)
release.yml release-binaries-on-merge matrix (unchanged — native binaries on mac/win/ubuntu)
release.yml tag-release ubuntu-latest self-hosted
release.yml github-release-on-tag ubuntu-latest (unchanged)
release.yml release-binaries-on-tag matrix (unchanged)

platforms: linux/amd64,linux/arm64 preserved everywhere — arm64 still emulated via QEMU on the runner host, but no per-job time limit.

Why

Multi-arch Rust builds under QEMU on GitHub-hosted runners are slow enough to risk the 6h job timeout. Self-hosted runs amd64 natively (fast) and emulates arm64 (slow but completes). Light jobs stay on GH-hosted so a single-host outage doesn't break PR gating or the release binary matrix.

Canonical references in the workflow comments (BR DevOps pages 1860 and 1905) were preserved without modification — design unchanged, only the runner target.

Test plan

  • Open a no-op PR against development — confirm build-pr.yml's three build jobs schedule on nate-wsl and complete.
  • Direct push to development (or trivial commit + revert) — confirm direct-push.yml's build matrix runs on self-hosted.
  • Confirm promote-on-merge still runs on GH-hosted and the :dev tag advances after a PR merges.
  • (When next semver release happens) confirm tag-release fires on self-hosted; github-release-on-tag + release-binaries-on-tag fire on GH-hosted.

Notes

  • Runner registered at org-level (bees-roadhouse), labels: self-hosted, Linux, X64, rust, docker, nate-wsl.
  • Currently single host (Nate's workstation, WSL2 Ubuntu). If nate-wsl is offline, jobs targeting it queue rather than fail — keep this in mind during workstation downtime. We can add more runners with the same label to scale.

🤖 Generated with Apis (Claude Opus 4.7)

Gumbees and others added 2 commits May 12, 2026 17:49
Heavy buildx multi-arch jobs (build-server, build-embedder, build-worker
in build-pr.yml; build in direct-push.yml; tag-release in release.yml)
now target the self-hosted runner pool labeled `nate-wsl`. Lightweight
jobs (guard, promote, github-release-*, release-binaries-*) stay on
GitHub-hosted so a single-host outage doesn't break PR gating or release
binary builds.

platforms: linux/amd64,linux/arm64 preserved; arm64 still emulated via
QEMU on the runner host, but no 6h per-job timeout (self-hosted has no
time cap besides 35-day max).

Co-Authored-By: Apis (Claude Opus 4.7) <nate.smith@dtctoday.com>
@Gumbees
Gumbees merged commit 9728e0a into development May 19, 2026
@Gumbees
Gumbees deleted the ci/self-hosted-runner branch May 19, 2026 20:52
Gumbees added a commit that referenced this pull request May 23, 2026
…GH-hosted (#98)

* refactor(ci): build-on-merge — drop PR-image-builds, drop retag, pin GH-hosted (closes #96)

The self-hosted runner pool (`nate-wsl`, introduced by #89) has been unreliable; queued jobs hang rather than fall back to GitHub-hosted, leaving PRs unmerged. The retag-on-merge model (introduced by #81) compounded the failure: if the PR-time build never completed, there was no image to retag, so stream tags drifted.

Simpler model:

- **Delete** `build-pr.yml` (per-PR image builds) and `promote-on-merge.yml` (the retag step).
- **Rename** `direct-push.yml` to `build-development.yml`; drop the PR-merge-commit guard so every push to development builds; pin `runs-on: ubuntu-latest`. Tags: `:dev`, `:dev-{sha}`, `:{version}-dev`, `:{version}-dev-{sha}`.
- **Modify** `release.yml`: add `build-release-images` (builds + pushes `:{version}`, `:{version}-{sha}`, `:release`, `:latest` on `ubuntu-latest`). Switch `tag-release` from self-hosted to `ubuntu-latest`. Update header comment block to drop the "after promote-on-merge has retagged" assumption.
- **Add** `verify-pr.yml`: cargo check + cargo clippy + cargo test on `ubuntu-latest`. Fast, image-free PR-time gating signal.
- **Keep** `generate-artifacts.yml` unchanged.

Self-hosted runners no longer appear in any `runs-on` list. They can return as a per-job opt-in later (e.g., via a repo variable) once a runner pool is reliable.

DEVELOPMENT.md updated: Workflow section, CI/CD opener, Contributor flow, "What runs on what" table, "Why this shape", "Tag conventions on GHCR", "Required status check" note, and the Versioning section's release blurb. `scripts/publish-pr-image.sh` header comments updated — the script remains as a local-experimentation helper but is no longer described as the CI emergency path.

Backfill on landing: the existing `:dev` / `:release` / `:latest` stream tags become stale; fresh builds emit them on the next push to development / release. No manual backfill needed.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* chore: regenerate SBOM and STRUCTURE

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This was referenced May 28, 2026
Gumbees added a commit that referenced this pull request May 28, 2026
* improvement(git): auto-resolve SBOM.md + STRUCTURE.md regen conflicts via merge=ours driver (closes #95)

generate-artifacts.yml lands an SBOM/STRUCTURE auto-commit on every PR push, and the same workflow regenerates them again on every merge to development. The two versions always disagree, so every open PR shows a conflict in those files immediately after each merge.

The conflict isn't a real disagreement — both versions are valid regenerations of the same derived artifact off slightly different parent trees. Tell git to keep ours (the target branch's version) on merge or rebase; the next CI push rewrites SBOM/STRUCTURE cleanly off the new tree.

Verified pattern on PR #93 and #94 today — each had to be rebased + force-pushed twice for the SBOM/STRUCTURE conflict alone after #89 + #92 + #93 landed in sequence.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* chore: regenerate SBOM and STRUCTURE

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant