Why: Between v0.82.x and v0.86.x, Prometheus Operator made breaking API changes across the Monitoring CRDs (ServiceMonitor, PodMonitor, Probe, ScrapeConfig). These were largely refactors of HTTP scraping configuration into a structured HTTPConfig block and related field renames.

Key breaking changes (relevant excerpts from upstream release notes/changelogs):

• HTTP scraping config fields moved under a new HTTPConfig struct, across ServiceMonitor/PodMonitor/Probe/ScrapeConfig:
  • followRedirects → HTTPConfig.FollowRedirects
  • enableHttp2 → HTTPConfig.EnableHTTP2
  • proxyURL → HTTPConfig.ProxyConfig.ProxyURL
  • tlsConfig → HTTPConfig.TLSConfig
• PodMonitor: PodMetricsEndpoint.BearerTokenSecret changed semantics (pointer type in newer APIs).
• Probe: ProberSpec.ProxyURL → ProberSpec.ProxyConfig.ProxyURL (and can be pointer).
• General naming normalization: EnableHttp2 → EnableHTTP2.

Evidence:

• Prometheus Operator releases: v0.83–v0.86 notes describe these structural moves. See:
  • https://github.com/prometheus-operator/prometheus-operator/releases/tag/v0.86.1
  • https://github.com/prometheus-operator/prometheus-operator/releases (scan v0.83–v0.86 for HTTPConfig consolidation and field renames)
• This PR already adapts the code to these changes in the following files, which confirms the requirement:
  • internal/component/prometheus/operator/configgen/config_gen_podmonitor.go
  • internal/component/prometheus/operator/configgen/config_gen_podmonitor_test.go
  • internal/component/prometheus/operator/configgen/config_gen_probe.go
  • internal/component/prometheus/operator/configgen/config_gen_probe_test.go
  • internal/component/prometheus/operator/configgen/config_gen_servicemonitor_test.go

Required code updates (shown as diffs you should make if not already done):

1. PodMonitor: Use HTTPConfig (EnableHTTP2, FollowRedirects, ProxyConfig.ProxyURL, TLSConfig). Also treat BearerTokenSecret as a pointer.

- if ep.FollowRedirects != nil {
-   cfg.HTTPClientConfig.FollowRedirects = *ep.FollowRedirects
- }
- if ep.EnableHttp2 != nil {
-   cfg.HTTPClientConfig.EnableHTTP2 = *ep.EnableHttp2
- }
- if ep.TLSConfig != nil {
-   cfg.HTTPClientConfig.TLSConfig, err = cg.generateSafeTLS(*ep.TLSConfig, m.Namespace)
- }
- if ep.BearerTokenSecret.Name != "" {
-   val, err := cg.Secrets.GetSecretValue(m.Namespace, ep.BearerTokenSecret)
- }
+ if ep.HTTPConfig.FollowRedirects != nil {
+   cfg.HTTPClientConfig.FollowRedirects = *ep.HTTPConfig.FollowRedirects
+ }
+ if ep.HTTPConfig.EnableHTTP2 != nil {
+   cfg.HTTPClientConfig.EnableHTTP2 = *ep.HTTPConfig.EnableHTTP2
+ }
+ if ep.HTTPConfig.TLSConfig != nil {
+   cfg.HTTPClientConfig.TLSConfig, err = cg.generateSafeTLS(*ep.HTTPConfig.TLSConfig, m.Namespace)
+ }
+ if ep.BearerTokenSecret != nil && ep.BearerTokenSecret.Name != "" {
+   val, err := cg.Secrets.GetSecretValue(m.Namespace, *ep.BearerTokenSecret)
+ }
+ if ep.HTTPConfig.ProxyConfig.ProxyURL != nil {
+   cfg.HTTPClientConfig.ProxyURL = parseURL(*ep.HTTPConfig.ProxyConfig.ProxyURL)
+ }

2. Probe: Move ProxyURL to ProxyConfig.ProxyURL (pointer) and honor HTTPConfig shape.

- if m.Spec.ProberSpec.ProxyURL != "" {
-   u, err := url.Parse(m.Spec.ProberSpec.ProxyURL)
+ if m.Spec.ProberSpec.ProxyURL != nil && *m.Spec.ProberSpec.ProxyURL != "" {
+   u, err := url.Parse(*m.Spec.ProberSpec.ProxyURL)
    ...
 }

3. Tests: Update fixtures to match the new structures (HTTPConfig and ProxyConfig nesting, EnableHTTP2 name, etc.)

- EnableHttp2: falsePtr,
- FollowRedirects: falsePtr,
- ProxyURL: &proxyURL,
- TLSConfig: &promopv1.SafeTLSConfig{ ... }
+ HTTPConfig: promopv1.HTTPConfig{
+   EnableHTTP2:     falsePtr,
+   FollowRedirects: falsePtr,
+   ProxyConfig: promopv1.ProxyConfig{
+     ProxyURL: &proxyURL,
+   },
+   TLSConfig: &promopv1.SafeTLSConfig{ ... },
+ }

Conclusion: This upgrade requires code changes that you’ve already made in this PR, aligning with the new Prometheus Operator API. No additional changes are needed beyond what’s shown above.

This is the API module that defines the Monitoring CRD structs. Same breaking changes as above apply here (HTTPConfig refactor, field renames, pointer semantics).

• You already updated usages to reflect:
  • EnableHTTP2 naming
  • HTTPConfig presence and nesting (ProxyConfig.ProxyURL, TLSConfig)
  • BearerTokenSecret pointer

No additional changes are required beyond the ones shown in the previous section.

Client generation follows the CRD changes but your code interacts with typed clients/informers via controller-runtime and typed listers (not directly with the generated clientsets here beyond informers/listing). The compile-time shape is covered by the changes you already made to the API structs. No additional code changes needed.

Summary of upstream changes:

• v0.22 targets Kubernetes 1.30 (k8s.io v0.34.x) and Go 1.21+.
• Requires aligned Kubernetes deps (which you already bumped: k8s.io/* v0.34.1).
• API surface used in this repo (controller.GetConfig(), shared informers) remains unchanged in your usage.

Code impact:

• Your new component uses controller.GetConfig() and typed informers/listers; these are compatible with v0.22.x.
• No code changes required, but ensure:
  • Go version in CI/toolchain is ≥ the minimum supported by controller-runtime v0.22.
  • Kubernetes client versions are aligned (they are: k8s.io/api/apimachinery/client-go v0.34.1).

Evidence:

• https://github.com/kubernetes-sigs/controller-runtime/releases/tag/v0.22.2

Bundled with the controller-runtime and k8s client upgrades. You don’t use component-base APIs directly in your code. No changes required.

Transitive alignment with k8s 1.30. Not used directly by your code; no changes required.

Transitive/util-only. No direct usage in your codebase; no changes required.

This module changes from indirect to direct require (same version). You’re importing and using alertmanager/config for Alertmanager config marshaling and validation. That API is compatible at v0.28.1 (as used). No code changes required.

Evidence in code:

• internal/mimir/client/alerts.go uses alertmanager/config (MarshalSecretValue, Config.String()).
• Tests confirm payload compatibility (internal/mimir/client/alerts_test.go, testdata).

Note: Your go.mod explicitly says this module is “replaced by a fork of v3.7.1.” The pseudo-version change here won’t affect builds if the replace directive still pins to the fork and v3.7.1. Therefore, the effective code used by your build remains unchanged.

Action:

• Verify the replace directive is still present and points to the expected fork/version (as commented in go.mod).
• If so, no code changes are needed.

These upgrades are likely pulled by controller-runtime v0.22 and k8s 1.30 alignment. You don’t use etcd APIs directly in your code; they are used internally by Kubernetes clients and controller machinery.

Action:

• No code changes required in your repo.
• Ensure your runtime (or integration test environments) are not pinned to an etcd server feature set incompatible with 3.6.x (only relevant if you spin up embedded etcd yourself; you do not).

References:

• https://github.com/etcd-io/etcd/releases/tag/v3.6.4

All of these are indirect dependencies (pulled by Prometheus Operator and/or Kubernetes/openapi toolchain). No direct usage in your codebase; no changes required.

Indirect dependency. No direct usage in your codebase; no changes required.