chore(release): v0.1.19

[dray92]

Release v0.1.19 of zxporter, published from the internal services monorepo.

The v0.1.19 tag has already been created and points at this branch's tip — ArgoCD and other tag consumers can use it immediately. This PR is only to advance public main to the released commit for browser convenience.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[gitar-bot]

⚠️ Bug: Re-enabling Flux/SchedulerMetrics/KEDA scaler collectors is a silent no-op

This release adds re-enable cases to handleDisabledCollectorsChange for the Argo CD and Flagger collectors only. Several other collectors added in the same release are missing: all eighteen Flux kinds (collector.FluxGitRepository, FluxKustomization, and so on), scheduler_placement_metric and keda_scaler_metrics. If one of these type strings is removed from a CollectionPolicy's disabledCollectors, the loop falls through to default: "Unknown collector type, skipping" and continues. The disable path already deregistered that collector, and nothing puts it back in pendingCollectors, so it stays off until the zxporter pod restarts.

The new buildCollectorFromSpecs helper already builds any collector type listed in resourceCollectorSpecs from the current config. Using it as the default fallback covers these types and any collector added later.

Fall back to the spec table for types without a dedicated case.:

default:
	var rt collector.ResourceType
	for _, t := range collector.AllResourceTypes() {
		if t.String() == collectorType {
			rt = t
		}
	}
	replacedCollector = r.buildCollectorFromSpecs(logger, rt, metricsClient)
	if replacedCollector == nil {
		logger.Info("Unknown collector type, skipping", "type", collectorType)
		continue
	}

• Apply fix

_{Check the box to apply the fix or reply for a change | Was this helpful? React with 👍 / 👎}

[gitar-bot]

CI failed: 1 lint failure in the helm chart tests caused by a line exceeding the maximum character length limit.

Overview

One error pattern was found across 1 analyzed log, indicating a linter failure in the PR code changes.

Failures

Golangci-Lint Line Length Violation (confidence: high)

• Type: tooling
• Affected jobs: 109014940914
• Related to change: yes
• Root cause: The linter check failed due to a line length violation (lll linter) in helm-chart/zxporter/chart_topology_spread_test.go at line 12, where a string literal is 162 characters long, exceeding the 120 character limit.
• Suggested fix: Break the long string literal across multiple lines so that no line exceeds 120 characters.

Summary

• Change-related failures: 1 linter error due to code formatting / line length in test files
• Infrastructure/flaky failures: 0
• Recommended action: Update helm-chart/zxporter/chart_topology_spread_test.go to wrap the long string literal within the 120-character line limit.

Code Review ⚠️ Changes requested 0 closed / 1 findings

🔴 High risk · Adds cluster-wide RBAC permissions and extensive eBPF/network telemetry behavior

Release v0.1.19 advances main to the released commit, but re-enabling Flux/SchedulerMetrics/KEDA scaler collectors is a silent no-op. When these collector types are removed from disabledCollectors, the handler falls through to the default case and skips re-registration, leaving them disabled until pod restart. Use the existing buildCollectorFromSpecs helper as the fallback to cover these types and future collectors.

⚠️ Bug: Re-enabling Flux/SchedulerMetrics/KEDA scaler collectors is a silent no-op

📄 internal/controller/collectionpolicy_controller.go:4867 📄 internal/controller/collectionpolicy_controller.go:4810-4824 📄 internal/controller/collectionpolicy_controller.go:527-541 📄 internal/controller/collectionpolicy_controller.go:3847-3861

This release adds re-enable cases to handleDisabledCollectorsChange for the Argo CD and Flagger collectors only. Several other collectors added in the same release are missing: all eighteen Flux kinds (collector.FluxGitRepository, FluxKustomization, and so on), scheduler_placement_metric and keda_scaler_metrics. If one of these type strings is removed from a CollectionPolicy's disabledCollectors, the loop falls through to default: "Unknown collector type, skipping" and continues. The disable path already deregistered that collector, and nothing puts it back in pendingCollectors, so it stays off until the zxporter pod restarts.

The new buildCollectorFromSpecs helper already builds any collector type listed in resourceCollectorSpecs from the current config. Using it as the default fallback covers these types and any collector added later.

Fall back to the spec table for types without a dedicated case.

default:
	var rt collector.ResourceType
	for _, t := range collector.AllResourceTypes() {
		if t.String() == collectorType {
			rt = t
		}
	}
	replacedCollector = r.buildCollectorFromSpecs(logger, rt, metricsClient)
	if replacedCollector == nil {
		logger.Info("Unknown collector type, skipping", "type", collectorType)
		continue
	}

🤖 Prompt for agents

Code Review: Release v0.1.19 advances main to the released commit, but re-enabling Flux/SchedulerMetrics/KEDA scaler collectors is a silent no-op. When these collector types are removed from `disabledCollectors`, the handler falls through to the `default` case and skips re-registration, leaving them disabled until pod restart. Use the existing `buildCollectorFromSpecs` helper as the fallback to cover these types and future collectors.

1. ⚠️ Bug: Re-enabling Flux/SchedulerMetrics/KEDA scaler collectors is a silent no-op
   Files: internal/controller/collectionpolicy_controller.go:4867, internal/controller/collectionpolicy_controller.go:4810-4824, internal/controller/collectionpolicy_controller.go:527-541, internal/controller/collectionpolicy_controller.go:3847-3861

   This release adds re-enable cases to `handleDisabledCollectorsChange` for the Argo CD and Flagger collectors only. Several other collectors added in the same release are missing: all eighteen Flux kinds (`collector.FluxGitRepository`, `FluxKustomization`, and so on), `scheduler_placement_metric` and `keda_scaler_metrics`. If one of these type strings is removed from a CollectionPolicy's `disabledCollectors`, the loop falls through to `default: "Unknown collector type, skipping"` and `continue`s. The disable path already deregistered that collector, and nothing puts it back in `pendingCollectors`, so it stays off until the zxporter pod restarts.
   
   The new `buildCollectorFromSpecs` helper already builds any collector type listed in `resourceCollectorSpecs` from the current config. Using it as the `default` fallback covers these types and any collector added later.

   Fix (Fall back to the spec table for types without a dedicated case.):
   default:
   	var rt collector.ResourceType
   	for _, t := range collector.AllResourceTypes() {
   		if t.String() == collectorType {
   			rt = t
   		}
   	}
   	replacedCollector = r.buildCollectorFromSpecs(logger, rt, metricsClient)
   	if replacedCollector == nil {
   		logger.Info("Unknown collector type, skipping", "type", collectorType)
   		continue
   	}

Review coverage

🤖 Auto-approval Not evaluated

📋 Rules No rules evaluated

🧪 Functional validation Not enabled · Set up

Tip

Comment Gitar fix CI or enable auto-apply: gitar auto-apply:on

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Counting what did not apply, without listing it.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[gitar-bot]

⚠️ This PR is blocked due to unresolved code review findings.

_{Configure merge blocking · Maintainers can dismiss this review.}