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

Aperta
  • Qualcosa non va?
#13,147 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@timothytlewis ci sta già lavorando.

Dal 1/6/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

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)

Lingua principale
C
Stelle
199
Fork
142
Merge medio
2h 33m
PR unite (30g)
145

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di pkgxdev/pantry

Tutte le issue di pkgxdev/pantry

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.