ci: drop gateway-prysm-canary from the gitops image bump - #59
ci: drop gateway-prysm-canary from the gitops image bump#59Taranpreet26311 wants to merge 1 commit into
Conversation
The canary workload has moved to the optimum-gateway Helm chart, so gitops no longer contains gateway-prysm-canary/deployment.yaml. Leaving it in the bump list breaks the whole step, not just the canary: `run:` executes under `bash -e`, so `sed` on a missing path aborts before lighthouse, nimbus or prysm are written, and the subsequent `git add` of the missing file would fail too. Every gateway build would go red. Consequence: the canary no longer auto-bumps. Its digest now lives in the chart's values/internal-prysm-canary.yaml and must be bumped there when promoting an image to the canary. Pairs with getoptimum/gitops#535 — merge this FIRST.
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 54 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository: getoptimum/coderabbit/.coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
Comment |
Gateways exist in one of two forms and migrate from the first to the second: Kustomize -> clusters/.../optimum/gateway-<flavour>/deployment.yaml Helm -> charts/optimum-gateway/values/internal-<flavour>.yaml The bump step now writes whichever form exists for each flavour, so a gateway moving to Helm needs no change here — its deployment.yaml disappears, its values file appears, and the bump follows it. The canary keeps receiving new images instead of silently falling behind. Every path is guarded with -f. `run:` executes under bash -e, so sed on a missing file aborted the whole step: one migrated gateway would have stopped lighthouse, nimbus and prysm from being bumped too, not just itself. The Helm sed is anchored to the `digest:` line so image.repository is never rewritten. Verified against real files: the Kustomize image and the Helm digest are both replaced and `repository: getoptimum/gateway` is untouched. Also: - Fails the step if nothing matched. A rename or restructure that silently matched no files previously looked identical to a successful run. - Warns per flavour that has neither form present. - Stages by directory rather than naming files, since a `git add` of a path that no longer exists fails the step. - Uses a literal loop list rather than word-splitting a variable. teku remains deliberately excluded: parked at replicas 0 on an older digest. Requires getoptimum/gitops#536 (chart in gitops) for the Helm path to exist; until then the -f guard simply skips it, so this is safe to merge first. Replaces #59, which dropped the canary from bumping altogether.
1 participant
Companion to getoptimum/gitops#535 (canary Kustomize → Helm). Merge this one first.
Why
The canary workload moves to the optimum-gateway Helm chart, so gitops no longer contains
gateway-prysm-canary/deployment.yaml.Leaving it in the bump list breaks the whole step, not just the canary:
run:steps execute underbash -e.sedon a missing path returns non-zero, the&&chain propagates it, and the step aborts — before lighthouse, nimbus or prysm are written. The latergit addof the missing file would fail as well. Every gateway build goes red, and the three remaining flavours silently stop being bumped.Change
Removes the canary from the
forloop and from thegit addlist. Nothing else touched.Consequence — worth being explicit
The canary no longer auto-bumps. Its digest now lives in the chart’s
values/internal-prysm-canary.yamland must be bumped there when promoting an image to the canary.That is a real regression in automation and the migration’s main rough edge: a digest duplicated in a values file drifts. It has already caught us twice — the values file was stale against
origin/mainon two separate occasions during this migration, each time pinning a superseded build.Worth deciding separately whether the chart should live somewhere CI can bump it, or whether the digest should come from gitops rather than being copied into values.
Ordering
mainhelm upgrade --installfor the canaryMerging #535 first leaves a window where every gateway build fails.