ci: the deploy gate waits on 5 of 7 component workloads
- Dominant language
- Go
- Stars
- 28
- Forks
- 11
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 55
Description
Both deploy gates wait on:
```
deploy/unbounded-operator
deploy/unbounded-net-controller
ds/unbounded-net-node
deploy/machina-controller
ds/gantry
```
`metalman` and `unbounded-storage-supervisor` are not in the list, so nothing in the release pipeline fails when either does not roll out. `internal/operator/imagecoverage_test.go` already records this as known non-coverage:
> it compares component names, not the repository lists under them ... (only by `hack/release/wait-rollouts.sh`, which omits metalman and storage)
Image coverage catches a component image that was never *built*. It does not catch one that was built and then does not start, which is what the rollout gate is for.
Adding them is not just two more arguments. Both are optional per-Site components (`SiteComponentSpec.Enabled`, `api/machina/v1alpha3/site_types.go`), so the gate has to ask whether the component is enabled for the Site being deployed before it waits on the workload - otherwise it blocks forever on a DaemonSet the operator was never going to create. `wait_exists` currently treats a missing workload as "keep waiting until CREATE_TIMEOUT_SECONDS", which is the right behaviour for an enabled component and the wrong one for a disabled component.
Sketch:
- read the Site's component spec once at the start of the gate
- skip, loudly, any workload whose component is disabled
- add both workloads to the list in `nightly.yaml` and `release-upgrade.yaml`
Worth doing: a release currently ships storage and metalman with no deploy-time verification at all.
Contributor guide
Research direction
Start with hack/release/wait-rollouts.sh, then inspect nightly.yaml and release-upgrade.yaml for the deploy gates. Read internal/operator/imagecoverage_test.go and api/machina/v1alpha3/site_types.go to understand the existing coverage note and optional Site components. Done means enabled metalman and unbounded-storage-supervisor workloads are checked, while disabled components are skipped loudly without blocking.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes, yaml
- Domain
- ci-cd, devops, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100