Problem
The Repo Radius deploy workflow consistently fails during Set up control plane when run from a private repository using the standard ubuntu-24.04 GitHub-hosted runner.
The workflow creates a single-node k3d cluster and installs Radius with both PostgreSQL and BuildKit enabled:
rad install kubernetes \
--set database.enabled=true \
--set rp.publicEndpointOverride=localhost \
--set dynamicrp.buildkit.enabled=true \
--set global.targetCluster.enabled=true
GitHub provides 2 vCPU to standard Linux runners for private/internal repositories, while public repositories receive 4 vCPU for the same runner label. The Radius chart requests:
- PostgreSQL:
2000m
- BuildKit:
200m
- k3s CoreDNS:
100m
- k3s metrics-server:
100m
The minimum scheduled requests therefore exceed the runner's entire CPU capacity before the remaining Radius control-plane pods are considered. PostgreSQL remains 0/1; UCP is configured to use that PostgreSQL service and consequently remains unavailable until Helm times out.
Reproduction
Repository workflow:
Observed error:
resource StatefulSet/radius-system/database not ready. status: InProgress, message: Ready: 0/1
resource Deployment/radius-system/ucp not ready. status: InProgress, message: Available: 0/1
context deadline exceeded
Four consecutive runs failed across Radius edge commits f3445ec, 7e9835d, and 2986f19. There were no relevant Helm chart changes across those commits.
The identical workflow succeeds on a public repository's standard 4-vCPU runner:
https://github.com/sk593/aks-store-demo/actions/runs/33093381579
Related issue
#9206 reported the same 2-vCPU PostgreSQL scheduling problem. It was closed after PostgreSQL became optional, but Repo Radius now unconditionally enables PostgreSQL for rad startup/rad shutdown, reintroducing the blocker for private/internal repositories.
Suggested fix
Lower database.resources.requests.cpu for the ephemeral Repo Radius control plane, either in the chart default or through an explicit override in setup-control-plane. PostgreSQL may retain a higher CPU limit while using a smaller scheduling request.
It would also help for setup failure diagnostics to capture pod descriptions and namespace events before Helm rollback removes the resources.
Problem
The Repo Radius deploy workflow consistently fails during
Set up control planewhen run from a private repository using the standardubuntu-24.04GitHub-hosted runner.The workflow creates a single-node k3d cluster and installs Radius with both PostgreSQL and BuildKit enabled:
GitHub provides 2 vCPU to standard Linux runners for private/internal repositories, while public repositories receive 4 vCPU for the same runner label. The Radius chart requests:
2000m200m100m100mThe minimum scheduled requests therefore exceed the runner's entire CPU capacity before the remaining Radius control-plane pods are considered. PostgreSQL remains
0/1; UCP is configured to use that PostgreSQL service and consequently remains unavailable until Helm times out.Reproduction
Repository workflow:
ubuntu-24.04.github/workflows/run-rad-commands-azure.ymlObserved error:
Four consecutive runs failed across Radius edge commits
f3445ec,7e9835d, and2986f19. There were no relevant Helm chart changes across those commits.The identical workflow succeeds on a public repository's standard 4-vCPU runner:
https://github.com/sk593/aks-store-demo/actions/runs/33093381579
Related issue
#9206 reported the same 2-vCPU PostgreSQL scheduling problem. It was closed after PostgreSQL became optional, but Repo Radius now unconditionally enables PostgreSQL for
rad startup/rad shutdown, reintroducing the blocker for private/internal repositories.Suggested fix
Lower
database.resources.requests.cpufor the ephemeral Repo Radius control plane, either in the chart default or through an explicit override insetup-control-plane. PostgreSQL may retain a higher CPU limit while using a smaller scheduling request.It would also help for setup failure diagnostics to capture pod descriptions and namespace events before Helm rollback removes the resources.