Skip to content

ci: use Depot runners for CI and release workflows#373

Open
ethanndickson wants to merge 1 commit into
mainfrom
ci/depot-runners
Open

ci: use Depot runners for CI and release workflows#373
ethanndickson wants to merge 1 commit into
mainfrom
ci/depot-runners

Conversation

@ethanndickson

Copy link
Copy Markdown
Member

Switches the CI and release workflows over to Depot runners, mirroring the pattern used in coder/coder. Each runs-on is guarded with github.repository_owner == 'coder' so forks continue to use ubuntu-latest.

Sizing

Picked per-job based on the actual workload:

Job Runner Why
build (test.yml) depot-ubuntu-22.04-4 go build + golangci-lint, 5 min cap
generate (test.yml) depot-ubuntu-22.04-4 go generate ./... (tfplugindocs), light
test (test.yml) depot-ubuntu-22.04-4 10-way Terraform version matrix already parallelizes; per-shard work is container start + serial TF apply/destroy, not CPU-bound
lint (test.yml) depot-ubuntu-22.04-4 make fmt + make gen diff check
goreleaser (release.yml) depot-ubuntu-22.04-8 Cross-compiles ~15 OS/arch binaries + GPG-signs; Go cross-build parallelizes well

The 4-core size for the acceptance-test matrix is deliberate: matrix fan-out already gives horizontal parallelism, and bumping each shard to 8 cores would roughly 2× Depot minutes for that workflow without meaningfully shortening wall-clock.

Mirrors the pattern used in coder/coder: keeps the github.repository_owner == 'coder' guard so forks still use ubuntu-latest.
@ethanndickson ethanndickson requested a review from johnstcn June 26, 2026 07:28
@ethanndickson ethanndickson self-assigned this Jun 26, 2026
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.

2 participants