Skip to content

ci: bump gateway digests in Helm values as well as Kustomize manifests - #60

Merged
Taranpreet26311 merged 1 commit into
mainfrom
ci/bump-helm-values-too
Aug 12, 2026
Merged

ci: bump gateway digests in Helm values as well as Kustomize manifests#60
Taranpreet26311 merged 1 commit into
mainfrom
ci/bump-helm-values-too

Conversation

@Taranpreet26311

Copy link
Copy Markdown
Contributor

Keeps every gateway auto-updating as it migrates from Kustomize to Helm. Replaces #59, which dropped the canary from bumping altogether — that was the wrong fix, since a canary that stops receiving new images is not a canary.

The problem

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 only knew about the first. When the canary moves to Helm, its deployment.yaml disappears — and because run: executes under bash -e, sed on the missing path aborted the entire step. One migrated gateway would have stopped lighthouse, nimbus and prysm from being bumped as well.

The fix

Write whichever form exists, per flavour:

for F in lighthouse nimbus prysm prysm-canary; do
  K="$MANIFEST_DIR/gateway-$F/deployment.yaml"
  H="$CHART_VALUES/internal-$F.yaml"
  [ -f "$K" ] && sed ... "$K"      # kustomize
  [ -f "$H" ] && sed ... "$H"      # helm
done

A gateway migrating needs no change here — its deployment.yaml goes, its values file arrives, and the bump follows it. Present and future.

Verified against real files

kustomize  prysm            image: ...@sha256:deadbeef...   ✓
helm       prysm-canary     digest: sha256:deadbeef...      ✓
                            repository: getoptimum/gateway  ← untouched ✓

The Helm sed is anchored to ^(\s*)digest:\s*sha256:[0-9a-f]+, so image.repository can never be rewritten by it.

Also hardened

  • Fails 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 — git add of a path that no longer exists fails the step.
  • Literal loop list instead of word-splitting a variable.

teku remains deliberately excluded: parked at replicas: 0 on an older digest and must not be dragged forward.

Ordering

Safe to merge first. The Helm path does not exist until getoptimum/gitops#536 lands; until then the -f guard simply skips it.

  1. this PR
  2. gitops#536 — chart into gitops
  3. gitops#535 — remove canary workload from Kustomize
  4. helm upgrade --install for the canary

@coderabbitai

coderabbitai Bot commented Aug 11, 2026

Copy link
Copy Markdown

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 28 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Repository: getoptimum/coderabbit/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 9a8fb35f-e6a8-4697-bbc6-60bbe7c0020a

📥 Commits

Reviewing files that changed from the base of the PR and between b1a946e and f1bf9a5.

📒 Files selected for processing (1)
  • .github/workflows/docker-publish.yml

Comment @coderabbitai help to get the list of available commands.

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.
@Taranpreet26311
Taranpreet26311 force-pushed the ci/bump-helm-values-too branch from 4065f5a to f1bf9a5 Compare August 12, 2026 09:18
@Taranpreet26311
Taranpreet26311 merged commit ebf2043 into main Aug 12, 2026
10 checks passed
@Taranpreet26311
Taranpreet26311 deleted the ci/bump-helm-values-too branch August 12, 2026 09:19
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.

1 participant