Skip to content

Sponsored self-hosted runner — would beefy hardware (M5 / EPYC class) be welcomed? #13147

@tannevaled

Description

@tannevaled

Exploratory question for maintainers

We have access to higher-capacity hardware (Apple Silicon M5 for darwin/aarch64, AMD EPYC for linux/x86-64) that we could make available to pkgxdev as a sponsored self-hosted GitHub Actions runner — not a donation, but a hosting (loan-based) arrangement where the hardware remains ours and we operate it.

Before going into specifics or drafting a formal proposal, we'd like to gauge whether the maintainers are open to this kind of arrangement at all.

Why we're asking

Several pantry recipes are currently parked because the default CI runners hit memory or build-time constraints:

  • CockroachDB (#13122 / #13123) — bazel-build needs 30-60 GB RAM at link
  • TiKV (#13089) — rust-rocksdb / Titan / grpcio bundled C++ — ~16-32 GB peak
  • Swift Linux toolchain (#13127) — Apple's Ubuntu-22.04-built binary needs that glibc
  • pyqt5 (#13064) — per-binding compile peaks ~6-8 GB; multi-binding bottle OOMs on linux runners even after the 10-recipe split
  • k0s (#13137) — Docker-based codegen pipeline (also relates to brewkit#351)
  • Various Top 300 / CNCF graduated projects of similar scale (Harbor, KubeVirt, etc.)

A sponsored runner with materially more RAM/cores/disk would unblock all of these — and is a pattern with established precedents (Equinix Metal hosts Cilium and Linkerd, AWS hosts Rust's build farm, etc.).

What we'd like to know before drafting specifics

  1. Is the maintainer team open in principle to accepting a sponsored self-hosted runner from a community contributor?
  2. What trust model would you require (build isolation expectations, secret scoping, audit rights, etc.)?
  3. What's the preferred relationship — directly with the contributor, or routed through an entity like CNCF/SPI/NumFOCUS?
  4. Are there constraints we should anticipate (network policy, log retention, monitoring access, etc.)?

We'd rather sketch the arrangement around your operational requirements than propose something tailored to our hardware first.

What we are NOT asking right now

  • Not committing specific specs yet
  • Not asking for any change to brewkit until the question is settled
  • Not pre-judging whether the answer should be "yes, please" or "no thank you, here's how to work around it instead"

Just opening the conversation. Happy to take this to a discussion / Slack / call if that's a better venue.

— A contributor active on pantry recently (see contribution history)

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions