Siphon: resolve the application image tag from the release manifest instead of pinning it in source

Scope: the Bridge/v2alpha1 work in progress. The Siphon reconciler is gated behind the bridge build tag and ENABLE_BRIDGE=true, ships in no release and no OLM bundle, so nothing here affects the current public version of the GitLab Operator.

Problem

internal/controller/siphon/values.go pins the Siphon application image tag in source:

const siphonImageTag = "0.0.130-beta"

That is a stopgap. The tag has to be bumped by hand for every Siphon release, and nothing ties it to the chart version the resource asks for, so a spec.chart.version and the application build it renders can drift apart silently.

Why it is pinned rather than derived

The Operator resolves the table definitions tag from the chart catalogue it carries (appVersion() in internal/controller/siphon/gitlab.go reads the GitLab chart's appVersion). The same trick does not work for Siphon:

  • the Siphon chart declares no appVersion;
  • the chart defaults image.tag to null, and siphon.imageTag in its _helpers.tpl returns that empty string;
  • the published application tags are 0.0.<n>-beta, unrelated to the chart's 1.21.0. The chart's own values-full.yaml pins image.tag: 0.0.25-beta by hand.

An unset tag is also not caught anywhere. The chart interpolates "{{ $imageRepo }}:{{ $imageTag }}", so the render succeeds, the release applies, and every pod fails InvalidImageName while the resource reports Initialized=True. Found during a local end-to-end run of the pipeline.

Proposal

Resolve the version from the release manifest rather than from source, the way the other component versions are resolved, and keep spec.chart.values.image.tag as the escape hatch.

Whatever the source of truth ends up being, the render should fail with a message naming the value to set when the tag cannot be resolved, rather than applying pods that cannot start.

Related