fix: updating expansion templates to add owner ref in expanded resources

[JaydipGabani]

What this PR does / why we need it:
This pull request enhances the resource expansion logic in the pkg/expansion package by ensuring that generated resources correctly set their ownerReferences metadata to point back to their parent resource. T

Which issue(s) this PR fixes (optional, using fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when the PR gets merged):
Fixes #4258

Special notes for your reviewer:
Is this a backward compatibility issue?
IMO it shouldn't be, but need one more ack on this.

[Copilot]

Pull request overview

This PR adds owner reference metadata to resources generated through expansion templates, establishing proper parent-child relationships between source and expanded resources. This enables Kubernetes garbage collection and provides better tracking of resource ownership.

Key changes:

• New ensureOwnerReference function that adds owner references to expanded resources
• Integration of owner reference creation in the expansion workflow
• Updated test fixtures to include owner references in expected outputs

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
pkg/expansion/metadata.go	New file implementing ensureOwnerReference to add parent owner references to expanded resources
pkg/expansion/system.go	Calls ensureOwnerReference after setting the resource name during expansion
pkg/expansion/system_test.go	Adds comprehensive unit tests for expandResource function covering various scenarios
pkg/expansion/fixtures/fixtures.go	Updates all test fixture Pod/Job/custom resource definitions to include owner references pointing to their parent resources

[Copilot]

The owner reference is missing the required uid field. According to Kubernetes API validation (k8s.io/apimachinery/pkg/api/validation.validateOwnerReference), UID is a required field for owner references and must not be empty. Without the UID, the owner reference will fail validation when the resource is submitted to the Kubernetes API server.

Add the UID field to the owner reference:

ownerRef := map[string]interface{}{
	"apiVersion": parentAPIVersion,
	"kind":       parentKind,
	"name":       parentName,
	"uid":        string(parent.GetUID()),
}

Suggested change

	"name": parentName,
	"name": parentName,
	"uid": string(parent.GetUID()),

[Copilot]

The validation should also check if the parent UID is empty before proceeding. Without a UID, the owner reference would be invalid according to Kubernetes API validation requirements.

Update the validation to include UID:

parentUID := parent.GetUID()
if parentAPIVersion == "" || parentKind == "" || parentName == "" || parentUID == "" {
	return
}

And then use parentUID when creating the owner reference.

[Copilot]

The duplicate detection logic is incomplete. According to Kubernetes API specifications, owner references are uniquely identified by their UID, not just by apiVersion, kind, and name. Two resources with the same name could have different UIDs (e.g., after deletion and recreation).

Update the duplicate check to use UID:

if refMap["uid"] == string(parent.GetUID()) {
	return
}

This ensures proper deduplication based on the actual resource instance, not just its name.

[Copilot]

[nitpick] The error from SetNestedSlice is silently ignored. If there's an issue setting the owner references (e.g., due to metadata corruption), this failure will be invisible to callers and could lead to resources being created without proper ownership tracking.

Consider either:

1. Logging the error for debugging purposes, or
2. Changing the function signature to return an error that can be handled by the caller

For example:

if err := unstructured.SetNestedSlice(resultant.Object, refs, "metadata", "ownerReferences"); err != nil {
	// log error or return it
}

[Copilot]

[nitpick] The error from NestedSlice is silently ignored. While returning early on error is reasonable, silently failing could mask underlying issues with the resource's metadata structure. Consider logging this error for debugging purposes, especially since this is new functionality being added.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 51.85185% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 40.70%. Comparing base (3350319) to head (fa44da4).
⚠️ Report is 501 commits behind head on master.

Files with missing lines	Patch %	Lines
pkg/expansion/system.go	51.85%	9 Missing and 4 partials ⚠️

❗ There is a different number of reports uploaded between BASE (3350319) and HEAD (fa44da4). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (3350319)	HEAD (fa44da4)
unittests	2	1

Additional details and impacted files

@@             Coverage Diff             @@
##           master    #4262       +/-   ##
===========================================
- Coverage   54.49%   40.70%   -13.79%     
===========================================
  Files         134      251      +117     
  Lines       12329    17750     +5421     
===========================================
+ Hits         6719     7226      +507     
- Misses       5116     9897     +4781     
- Partials      494      627      +133     

Flag	Coverage Δ
unittests	40.70% <51.85%> (-13.79%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.