ci: build releases on the dedicated runner pool #1

marco · 2026-09-11T23:16:36Z

marco commented

2026-09-11 23:16:36 +00:00

Contexto

El release de snitch pedía ubuntu-latest, que hoy atienden los runners de sitio de infra01. Es uno de los consumidores que faltaban en la migración de bitua/network#243.

Cambio

runs-on: [x86_64, debian]. El job compila un binario Go con CGO_ENABLED=0 y publica un asset linux_amd64, así que queda pineado a amd64 en vez del pool mixto.

La imagen runner-image:trixie del pool nuevo trae git, jq, curl, tar y node 24 para las JS actions (actions/checkout@v4, actions/setup-go@v5), que es todo lo que usa este workflow. No cambian steps, pins ni el flujo de release.

Validación

YAML validado localmente. El workflow sólo dispara en tags v*, así que la prueba real llega con el próximo release; no se creó un tag de prueba para forzarla.

## Contexto El release de snitch pedía `ubuntu-latest`, que hoy atienden los runners de sitio de infra01. Es uno de los consumidores que faltaban en la migración de bitua/network#243. ## Cambio `runs-on: [x86_64, debian]`. El job compila un binario Go con `CGO_ENABLED=0` y publica un asset `linux_amd64`, así que queda pineado a amd64 en vez del pool mixto. La imagen `runner-image:trixie` del pool nuevo trae git, jq, curl, tar y node 24 para las JS actions (`actions/checkout@v4`, `actions/setup-go@v5`), que es todo lo que usa este workflow. No cambian steps, pins ni el flujo de release. ## Validación YAML validado localmente. El workflow sólo dispara en tags `v*`, así que la prueba real llega con el próximo release; no se creó un tag de prueba para forzarla.

marco added 1 commit 2026-09-11 23:16:36 +00:00

ci: build releases on the dedicated runner pool

Botua One-line runner label migration is correct and consistent with sibling repos; approved.

f76b887316

El job pedía `ubuntu-latest`, atendido por los runners de sitio de infra01. Publica un asset amd64, así que queda en `[x86_64, debian]`. Refs bitua/network#243.

botua-bot commented

2026-09-11 23:16:38 +00:00

✅ Botua — Approved

Review: `ci: build releases on the dedicated runner pool`

Verdict: Approved — one-line, low-risk CI change.

What changed

.gitea/workflows/release.yml:

-    runs-on: ubuntu-latest
+    runs-on: [x86_64, debian]

This is the only hunk. name, trigger, steps, pins and release logic are untouched.

Assessment

Correct scoping of the migration. Only the Gitea release job moves to the new pool. .github/workflows/release.yaml keeps GitHub-hosted runners, which is expected (it can't target the self-hosted bitua pool). Good separation.
amd64 pinning is justified. The job builds with CGO_ENABLED=0 and packages snitch_${VER}_linux_amd64.tar.gz, so requiring x86_64 avoids the mixed-arch pool. The debian label matches the runner-image:trixie (Debian) base described.
Label convention looks consistent. The sibling bitua/zigfetch release workflow uses the identical runs-on: [x86_64, debian], so this matches the org-wide migration from bitua/network#243.
Tooling requirements. The job only needs git (checkout), tar, curl, jq, plus a Node runtime for the two JS actions (actions/checkout@v4, actions/setup-go@v5). Go itself is provisioned by setup-go from go-version-file: go.mod, so no Go is required in the image. All are claimed present in the new image.

Residual risk (non-blocking)

As the author notes, this can't be exercised without pushing a v* tag, so the first real signal is the next release. Given the runner image contents and that setup-go downloads the toolchain (needs network from the new pool), I'd just keep an eye on the first tag-triggered run.
No changes requested.

Reviewed by Botua — deepseek/deepseek-v4-flash

## ✅ Botua — Approved ## Review: `ci: build releases on the dedicated runner pool` **Verdict: Approved** — one-line, low-risk CI change. ### What changed `.gitea/workflows/release.yml`: ```diff - runs-on: ubuntu-latest + runs-on: [x86_64, debian] ``` This is the only hunk. `name`, trigger, steps, pins and release logic are untouched. ### Assessment - **Correct scoping of the migration.** Only the Gitea release job moves to the new pool. `.github/workflows/release.yaml` keeps GitHub-hosted runners, which is expected (it can't target the self-hosted bitua pool). Good separation. - **amd64 pinning is justified.** The job builds with `CGO_ENABLED=0` and packages `snitch_${VER}_linux_amd64.tar.gz`, so requiring `x86_64` avoids the mixed-arch pool. The `debian` label matches the `runner-image:trixie` (Debian) base described. - **Label convention looks consistent.** The sibling `bitua/zigfetch` release workflow uses the identical `runs-on: [x86_64, debian]`, so this matches the org-wide migration from bitua/network#243. - **Tooling requirements.** The job only needs `git` (checkout), `tar`, `curl`, `jq`, plus a Node runtime for the two JS actions (`actions/checkout@v4`, `actions/setup-go@v5`). Go itself is provisioned by `setup-go` from `go-version-file: go.mod`, so no Go is required in the image. All are claimed present in the new image. ### Residual risk (non-blocking) - As the author notes, this can't be exercised without pushing a `v*` tag, so the first real signal is the next release. Given the runner image contents and that `setup-go` downloads the toolchain (needs network from the new pool), I'd just keep an eye on the first tag-triggered run. - No changes requested. --- *Reviewed by Botua — `deepseek/deepseek-v4-flash`*

marco merged commit 2142eac620 into master

2026-09-12 00:13:25 +00:00

marco referenced this issue from a commit

2026-09-12 00:13:26 +00:00

ci: build releases on the dedicated runner pool (#1)

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bitua/snitch#1