feat: introduce default version flags for Prometheus, Alertmanager and Thanos

[davidquan1]

Description

Currently, the Prometheus Operator defaults to the latest stable version of operands (e.g., Prometheus v3.12.0) if .spec.version is omitted in the Custom Resource. This creates a "silent trap" for platform maintainers who use the -default-base-image flags to globally enforce specific, security-hardened LTS images (especially via digests).

In such cases, the Operator continues to render configuration based on its hardcoded bleeding-edge defaults. This leads to functional disconnects, such as generating invalid YAML schema (e.g., the storage.tsdb.retention field introduced in v3.11.0) for older LTS versions (like v3.5.4), causing operand pods to crash.

This PR introduces three new command-line flags to bridge this gap:

• -prometheus-default-version
• -alertmanager-default-version
• -thanos-default-version
  These flags allow maintainers to explicitly sync the "assumed default version" with their "overridden default image," ensuring functional consistency by default when .spec.version is not defined in the Custom Resources.

Closes: #8641

Type of change

What type of changes does your code introduce to the Prometheus operator? Put an x in the box that apply.

• CHANGE (fix or feature that would cause existing functionality to not work as expected)
• FEATURE (non-breaking change which adds functionality)
• BUGFIX (non-breaking change which fixes an issue)
• ENHANCEMENT (non-breaking change which improves existing functionality)
• NONE (if none of the other choices apply. Example, tooling, build system, CI, docs, etc.)

Verification

• Added unit tests in pkg/prometheus/promcfg_test.go to verify that NewConfigGenerator respects the custom default version.
• Added unit tests in pkg/alertmanager/statefulset_test.go and pkg/thanos/statefulset_test.go to ensure StatefulSet image paths and configuration logic use the provided default versions as fallbacks.
• Verified that all new tests pass and existing functionality remains intact.

Changelog entry

[ENHANCEMENT] Introduce --prometheus-default-version, --alertmanager-default-version, and --thanos-default-version flags to explicitly define default fallback versions for configuration rendering and image building.

[davidquan1]

Hi @simonpasquier,

Could you please help review this PR? It implements the requested flags for setting default component versions (Prometheus, Alertmanager, and Thanos) in the operator.

Thanks!

[davidquan1]

Hi @simonpasquier,

All comments have been addressed. Here is a summary of the changes:

• Help Text: Clarified the help text for the new default version flags as requested.
• Redundant Logic: Removed the redundant assignments in the bootstrap function.
• Tests & Fallback Logic: I initially reverted the test changes as suggested. However, doing so caused several unit tests (such as TestProvisionAlertmanagerConfiguration) to fail with: strconv.ParseUint: parsing "": invalid syntax.
  This happened because in the unit test context, the CLI flags are not evaluated, leaving the config version as an empty string. To address this gracefully without inflating the test code, I improved the fallback logic in the production code (e.g., in pkg/alertmanager/operator.go). It now safely falls back to operator.DefaultAlertmanagerVersion if both Spec.Version and the CLI config flag are empty. This makes the production code more robust against uninitialized configurations while keeping our test changes to a bare minimum.
• Upstream Sync: I've also merged the latest upstream/main to resolve conflicts and ensured that no upstream test cases were accidentally dropped during the process.

The PR is now ready for another look. Could you please review it again when you have a moment? Thank you!

[davidquan1]

Hi @simonpasquier,
Could you please help review this again ? Thanks.

[davidquan1]

Hi @simonpasquier,
Could you please help review this? Thanks.