fix(customresourcestate): do not write GVK labels into the shared config

[mrueg]

What this PR does / why we need it:

compile takes Resource by value, but CommonLabels is a map, so the copy shares it with the configured resource and with every other copy made from it — and wildcard resolution produces one copy per discovered GVK:

if resource.CommonLabels == nil {
	resource.CommonLabels = map[string]string{}
}
resource.CommonLabels[customResourceState+"_group"] = resource.GroupVersionKind.Group
resource.CommonLabels[customResourceState+"_version"] = resource.GroupVersionKind.Version
resource.CommonLabels[customResourceState+"_kind"] = resource.GroupVersionKind.Kind

Those three writes go into a map every copy points at, and into the user's configuration. Compiling myteam.io/v1 Foo and then myteam.io/v2 Bar from one configured resource leaves the caller's map as:

expected: map[string]string{"team":"myteam"}
actual:   map[string]string{"customresource_group":"myteam.io",
                            "customresource_kind":"Bar",
                            "customresource_version":"v2",
                            "team":"myteam"}

To be clear about severity: the emitted metrics are correct today. Each compile overwrites all three keys before Merge copies them into the family, and factories are built one at a time, so no family ends up with another GVK's labels. This is a hazard rather than a live bug — but it is one concurrent or partially-overwriting compile away from being one, and mutating configuration the caller owns is wrong regardless.

Building a new map removes the sharing. The test asserts both that each resolution keeps its own GVK labels and that the configured map is left as the user wrote it; the second assertion fails on main with the output above.

How does this change affect the cardinality of KSM: does not change cardinality

Which issue(s) this PR fixes: N/A

Summary by CodeRabbit

• Bug Fixes

  • Fixed an issue where resources resolved from wildcards could share or overwrite labels.
  • Common labels now remain unchanged when resource-specific labels are added.
  • Resources with different group, version, and kind values retain independent labels, improving label accuracy and consistency.

• Tests

  • Added regression coverage for label isolation and preservation of configured common labels.

[kubernetes-prow]

This issue is currently awaiting triage.

If kube-state-metrics contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 7a04355f-2a96-4026-937d-74da09747497

📥 Commits

Reviewing files that changed from the base of the PR and between 2c16de5 and 54778db.

📒 Files selected for processing (1)

• pkg/customresourcestate/registry_factory_test.go

🚧 Files skipped from review as they are similar to previous changes (1)

• pkg/customresourcestate/registry_factory_test.go

Included review availability: Your plan provides up to 8 included reviews per hour; 6 remain after this review.

---

📝 Walkthrough

Walkthrough

The compile path copies CommonLabels before adding group, version, and kind labels. A regression test verifies that compiled resources use independent label maps and that the configured labels remain unchanged.

Changes

Common-label isolation

Layer / File(s)	Summary
Copy labels before GVK enrichment pkg/customresourcestate/registry_factory.go, pkg/customresourcestate/registry_factory_test.go	compile copies CommonLabels before adding GVK labels. The regression test verifies independent resource maps and unchanged configured labels.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: ⚪ Minimal · up to 54778

The change prevents GVK labels from mutating shared configuration while preserving per-resource labels; no actionable merge-blocking risk remains beyond normal checks.

Suggested reviewers: nmn3m

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main fix: preventing GVK labels from modifying the shared custom resource configuration.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[bhope]

/lgtm
/hold

Feel free to unhold.

[bhope]

We probably may not need them in the tests. WDYT?

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bhope, mrueg

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [bhope,mrueg]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kubernetes-prow]

New changes are detected. LGTM label has been removed.