feat: labeling all resources created by a zarf package by sgettys · Pull Request #4194 · zarf-dev/zarf

sgettys · 2025-09-17T22:19:15Z

Description

Adds labels to all resources created by a zarf package:

zarf.dev/package: <package name>
zarf.dev/namespace-override: <namespace if provided>

This will allow for easy filtering of resources associated with a zarf package using label selectors.

Related Issue

Fixes #3625

Checklist before merging

Test, docs, adr added or updated as needed
Contributor Guide Steps followed

Signed-off-by: Steven Gettys <steven.gettys@defenseunicorns.com>

netlify · 2025-09-17T22:19:21Z

✅ Deploy Preview for zarf-docs ready!

Name	Link
🔨 Latest commit	`f0b64fe`
🔍 Latest deploy log	https://app.netlify.com/projects/zarf-docs/deploys/68d6ea92095b530008b585f4
😎 Deploy Preview	https://deploy-preview-4194--zarf-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

Signed-off-by: Steven Gettys <steven.gettys@defenseunicorns.com>

codecov · 2025-09-24T15:14:53Z

Codecov Report

❌ Patch coverage is 17.89474% with 78 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/internal/packager/helm/post-render.go	0.00%	45 Missing ⚠️
src/internal/packager/helm/zarf.go	0.00%	26 Missing ⚠️
src/pkg/packager/deploy.go	0.00%	5 Missing ⚠️
src/internal/packager/helm/chart.go	0.00%	2 Missing ⚠️

Files with missing lines	Coverage Δ
src/pkg/cluster/cluster.go	`36.57% <ø> (ø)`
src/pkg/cluster/injector.go	`65.62% <100.00%> (+0.69%)`	⬆️
src/internal/packager/helm/chart.go	`1.32% <0.00%> (ø)`
src/pkg/packager/deploy.go	`0.00% <0.00%> (ø)`
src/internal/packager/helm/zarf.go	`0.00% <0.00%> (ø)`
src/internal/packager/helm/post-render.go	`0.00% <0.00%> (ø)`

🚀 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.

AustinAbro321

Thanks for making this change, I think it will be a positive for the project. Added a few nits and questions around scope

AustinAbro321 · 2025-09-24T16:10:47Z

+	// PackageLabel is the label used to identify the owning of package.
+	PackageLabel string = "zarf.dev/package"
+	// NamespaceOverrideLabel is the label used to identify the namespace override.
+	NamespaceOverrideLabel string = "zarf.dev/namespace-override"


A better place to put these constants would be in this block https://github.com/zarf-dev/zarf/blob/main/src/pkg/cluster/cluster.go#L31-L38

AustinAbro321 · 2025-09-24T16:17:28Z

 		return nil, fmt.Errorf("action configuration required to run post renderer")
 	}
-	if variableConfig == nil {
+	if opts.VariableConfig == nil {


I'd rather not have this function take opts. While it's semantically nicer, generally opts shouldn't be required. Also one of the goals with opts is to avoid breaking changes in function signatures, but since this is private we don't have to worry about that.

I initially had it that way then went to opts because of the signature size and the fact that it was basically all of the "ops". I'm fine to revert back to explicit fields though

AustinAbro321 · 2025-09-24T17:29:25Z

 			}
 		}
-
+		namespace.Labels = r.setPackageLabels(namespace.Labels)


One implication that I'm thinking about here is that if two packages deploy resources to the same namespace then whichever deploy was more recent will take over and the label will change. Also, Zarf and Helm do not delete namespaces as well so these labels will stick around after the packages are removed from the cluster. Helm for instance doesn't add the app.kubernetes.io/name label to namespaces it creates. Still, these aren't necessarily a deal breaker to adding labels to namespaces as these side effects are relatively inconsequential, but I would like to evaluate it.

Could you provide more info about your use case @sgettys @Racer159. Is having this label on a namespace useful?

We don't actually need the namespaces - we were just trying to be complete here - I would be fine with just not labeling namespaces actually - the need we had was for tracking Pods / Pod Owner resources.

My thought around this was this label would be useful to at least denote the latest zarf package to operate against that namespace assuming multiple packages operate against it. We also discussed having a list of packages and appending instead of replacing but that could be confusing especially since you'd have to manage the label removal on package remove. In general I'm a fan of "labeling everything" including namespaces and this will at the bare minimum be a highly visible way to know if zarf has operated against a namespace or not

I'm still somewhat torn, I could see it being useful on occasion. While it'd be rare, the argument against adding the label to namespaces is to avoid a user doing something such as making a script where they grab the namespaces deployed by their package, but suddenly having that script break when another package is deployed to that namespace. I agree that adding and removing different packages from the label is not worth the complexity.

I'm curious what the other @zarf-dev/maintainers think.

Now that we have this functionality available it will be very easy to add this in for namespaces down the road if the use cases start popping up. I'll remove for now

My 2 cents are that it is easy to add back if we need to in the future and can be left out as @sgettys mentioned - I do like completeness but if there are unexpected side effects that folks need to take into account it is worth holding off until we see more usecases - a list would be more complete but has its own side effects (what happens when a package is removed and the namespace is owned by two packages?).

AustinAbro321 · 2025-09-24T17:51:55Z

+	stdOut, stdErr, err = e2e.Kubectl(t, "wait", "deployment", "-l", "zarf.dev/package=manifests", "--for=condition=Available", "--all-namespaces", "--timeout=1m")
+	require.NoError(t, err, stdOut, stdErr)


So this is a bit interesting, initially I was going to say that this is unnecessary since Zarf waits for resources to be ready by default, but it actually is necessary because the podinfo deployment has an hpa which usually doesn't start scaling until after the deployment is already considered ready by Zarf. Probably it would be fine, but I don't want the hpa to take too long and not get caught by this wait, or make a third pod and fail the test. I think it's simpler to just test what we want in the dos-games test above.

I do at least like selecting multiple resources from the same package and since "package pods" is really what I'm getting at with this whole labeling thing IMO this is a good testcase. I can make it less restrictive on number of pods though to account for hpa!

Sounds good, but you should check for one or more replicas. A flake happened here because the check occurred before the hpa bumped up the replica count to two. https://github.com/zarf-dev/zarf/actions/runs/18012570063/job/51253428537?pr=4194

Yeah I added that. Getting ready to push

Signed-off-by: Steven Gettys <steven.gettys@defenseunicorns.com>

AustinAbro321 · 2025-09-25T17:35:16Z


 // UpdateZarfRegistryValues updates the Zarf registry deployment with the new state values
 func UpdateZarfRegistryValues(ctx context.Context, opts InstallUpgradeOptions) error {
+	pkg, err := opts.Cluster.GetDeployedPackage(ctx, "init")


To make this work with custom named init packages we could use cluster.GetDeployedZarfPackages and grab the first package with kind: ZarfInitConfig

Can we guarantee only a single ZarfInitConfig type?

I have seen before situations where there are multiple ZarfInitConfig packages deployed. The most complete thing to do would be check for a package with ZarfInitConfig and a component named zarf-registry. Same with the agent update, check for a package with ZarfInitConfig and a component named zarf-agent.

Technically still possible for there to be two packages with those component names deployed, but I can't imagine a use case for it.

Signed-off-by: Steven Gettys <steven.gettys@defenseunicorns.com>

AustinAbro321 · 2025-09-26T13:14:53Z

 		return nil, fmt.Errorf("variable configuration required to run post renderer")
 	}
+	if pkgName == "" {
+		return nil, fmt.Errorf("package required to run post renderer")


Suggested change

return nil, fmt.Errorf("package required to run post renderer")

return nil, fmt.Errorf("package name required to run post renderer")

AustinAbro321 · 2025-09-26T13:15:37Z

 		if err := yaml.Unmarshal([]byte(resource.Content), rawData); err != nil {
 			return fmt.Errorf("failed to unmarshal manifest: %w", err)
 		}
+		// If the object is empty, it's a blank resource, so we skip it. If the package is nil, we're not in a package and we don't want to add labels.


Suggested change

// If the object is empty, it's a blank resource, so we skip it. If the package is nil, we're not in a package and we don't want to add labels.

// If the object is empty, it's a blank resource, so we skip it. If the package name is empty we don't add labels.

AustinAbro321 · 2025-09-26T13:17:34Z


 // StartInjection initializes a Zarf injection into the cluster.
-func (c *Cluster) StartInjection(ctx context.Context, tmpDir, imagesDir string, injectorSeedSrcs []string, registryNodePort int) error {
+func (c *Cluster) StartInjection(ctx context.Context, tmpDir, imagesDir string, injectorSeedSrcs []string, registryNodePort int, pkg *v1alpha1.ZarfPackage) error {


Lets also use a string for package name here

AustinAbro321

A few small comments, very close to good to go

Signed-off-by: Steven Gettys <steven.gettys@defenseunicorns.com>

AustinAbro321 · 2025-09-26T19:00:39Z

+
+func findInitPackageWithComponent(pkgs []state.DeployedPackage, componentName string) string {
+	for _, pkg := range pkgs {
+		if pkg.Data.Kind == "ZarfInitConfig" {


Suggested change

if pkg.Data.Kind == "ZarfInitConfig" {

if pkg.Data.Kind == v1alpha1.ZarfInitConfig {

Signed-off-by: Steven Gettys <steven.gettys@defenseunicorns.com>

AustinAbro321

LGTM, nice work

brandtkeller

LGTM - Thanks @Racer159 & @AustinAbro321 for doing the heavy lifting on review.

brandtkeller · 2025-09-26T19:53:49Z

 		for _, serverNamespace := range namespaceList.Items {
 			if serverNamespace.Name == name {
 				existingNamespace = true
+				break


++ good catch

feat: labeling all resources created by a zarf package

718e1c3

Signed-off-by: Steven Gettys <steven.gettys@defenseunicorns.com>

Merge branch 'main' into 3625_label_zarf_resources_with_package_name

36eed92

sgettys marked this pull request as ready for review September 17, 2025 22:23

sgettys requested review from a team as code owners September 17, 2025 22:23

Racer159 reviewed Sep 17, 2025

View reviewed changes

chore: addressed review feedback

5f1205b

Signed-off-by: Steven Gettys <steven.gettys@defenseunicorns.com>

Racer159 reviewed Sep 19, 2025

View reviewed changes

Comment thread src/internal/packager/helm/post-render.go Outdated

sgettys and others added 3 commits September 23, 2025 08:43

chore: addressed review feedback

702abee

Signed-off-by: Steven Gettys <steven.gettys@defenseunicorns.com>

chore: require pkg for newRenderer

59009b0

Signed-off-by: Steven Gettys <steven.gettys@defenseunicorns.com>

Merge branch 'main' into 3625_label_zarf_resources_with_package_name

da2f2e6

AustinAbro321 requested changes Sep 24, 2025

View reviewed changes

sgettys added 2 commits September 25, 2025 08:28

chore: addressed review feedback

89d089f

Signed-off-by: Steven Gettys <steven.gettys@defenseunicorns.com>

chore: fixed lint

a05bad4

Signed-off-by: Steven Gettys <steven.gettys@defenseunicorns.com>

AustinAbro321 reviewed Sep 25, 2025

View reviewed changes

Comment thread src/internal/packager/helm/chart.go Outdated

AustinAbro321 reviewed Sep 25, 2025

View reviewed changes

Comment thread src/pkg/cluster/cluster.go Outdated

chore: review feedback

414f8fe

Signed-off-by: Steven Gettys <steven.gettys@defenseunicorns.com>

AustinAbro321 reviewed Sep 26, 2025

View reviewed changes

sgettys and others added 2 commits September 26, 2025 09:35

chore: review feedback

b00ef3e

Signed-off-by: Steven Gettys <steven.gettys@defenseunicorns.com>

Merge branch 'main' into 3625_label_zarf_resources_with_package_name

602ad31

AustinAbro321 reviewed Sep 26, 2025

View reviewed changes

sgettys and others added 2 commits September 26, 2025 12:32

chore: review feedback

2cbf09c

Signed-off-by: Steven Gettys <steven.gettys@defenseunicorns.com>

Merge branch 'main' into 3625_label_zarf_resources_with_package_name

f0b64fe

AustinAbro321 approved these changes Sep 26, 2025

View reviewed changes

brandtkeller approved these changes Sep 26, 2025

View reviewed changes

brandtkeller added this pull request to the merge queue Sep 26, 2025

Merged via the queue into zarf-dev:main with commit 6c4aa24 Sep 26, 2025
27 checks passed

brandtkeller mentioned this pull request Jan 22, 2026

fix(helm): preserve block scalar semantics #4541

Merged

2 tasks

		stdOut, stdErr, err = e2e.Kubectl(t, "wait", "deployment", "-l", "zarf.dev/package=manifests", "--for=condition=Available", "--all-namespaces", "--timeout=1m")
		require.NoError(t, err, stdOut, stdErr)

	return nil, fmt.Errorf("package required to run post renderer")
	return nil, fmt.Errorf("package name required to run post renderer")

	// If the object is empty, it's a blank resource, so we skip it. If the package is nil, we're not in a package and we don't want to add labels.
	// If the object is empty, it's a blank resource, so we skip it. If the package name is empty we don't add labels.

	if pkg.Data.Kind == "ZarfInitConfig" {
	if pkg.Data.Kind == v1alpha1.ZarfInitConfig {

Conversation

sgettys commented Sep 17, 2025

Description

Related Issue

Checklist before merging

Uh oh!

netlify Bot commented Sep 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for zarf-docs ready!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

codecov Bot commented Sep 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

AustinAbro321 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AustinAbro321 Sep 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AustinAbro321 Sep 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AustinAbro321 Sep 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AustinAbro321 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AustinAbro321 left a comment

Choose a reason for hiding this comment

Uh oh!

brandtkeller left a comment

Choose a reason for hiding this comment

netlify Bot commented Sep 17, 2025 •

edited

Loading

codecov Bot commented Sep 24, 2025 •

edited

Loading

AustinAbro321 Sep 24, 2025 •

edited

Loading

AustinAbro321 Sep 24, 2025 •

edited

Loading

AustinAbro321 Sep 24, 2025 •

edited

Loading