feat: create helm chart for zarf-agent

[JeffResc]

Description

Converts the zarf-agent manifests to a helm chart, allowing users to customize various values such as affinity and tolerations on the deployment.

Related Issue

Fixes #3620

Checklist before merging

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

[netlify]

✅ Deploy Preview for zarf-docs canceled.

Name	Link
🔨 Latest commit	d1706d8
🔍 Latest deploy log	https://app.netlify.com/projects/zarf-docs/deploys/68409ddf90f24400080da3e4

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 7 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/internal/packager/helm/zarf.go	0.00%	7 Missing ⚠️

Files with missing lines	Coverage Δ
src/internal/packager/helm/zarf.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.

[brandtkeller]

I believe we're missing a baseline values.yaml for the chart (living beside the Chart.yaml) that would serve as a default values definition that agent-values.yaml could then overlay at the Zarf component level.

[JeffResc]

I believe we're missing a baseline values.yaml for the chart (living beside the Chart.yaml) that would serve as a default values definition that agent-values.yaml could then overlay at the Zarf component level.

I'm not sure there's a need to have any other default values outside of the ones provided by agent-values.yaml. Would an acceptable solution be to move the agent-values.yaml into the chart/values.yaml and remove the valuesFiles reference from zarf.yaml?

[brandtkeller]

I'm not sure there's a need to have any other default values outside of the ones provided by agent-values.yaml. Would an acceptable solution be to move the agent-values.yaml into the chart/values.yaml and remove the valuesFiles reference from zarf.yaml?

Speaking strictly from a helm chart correctness perspective - the current state will fail helm lint . Much like the zarf-registry package providing a valid chart which we then have values modified at the zarf component layer - I'd opt to follow the same pattern.

[JeffResc]

Yeah, I agree. There should definitely be a baseline values.yaml in the chart/ directory that I missed. Latest commit moves the values into that file and removes the overrides done at the Zarf package level.

[JeffResc]

Just realized upgrade testing on this is going to be broken it was using a zarf-generated helm chart before, so the updated release name annotations won't match. The only solution I can think is to patch the existing resources before deploy, but that's hacky and would have to live in the codebase forever, so I don't like that approach. I'm open to ideas on how to solve this more elegantly.

[brandtkeller]

Just realized upgrade testing on this is going to be broken it was using a zarf-generated helm chart before, so the updated release name annotations won't match. The only solution I can think is to patch the existing resources before deploy, but that's hacky and would have to live in the codebase forever, so I don't like that approach. I'm open to ideas on how to solve this more elegantly.

Upgrade testing is where we expected this to potentially get hairy. I will look at this for my next task and see if anything stands out (likely tomorrow).

[brandtkeller]

Possible path forward - appreciate your patience.

[brandtkeller]

Looks like some differences between the old/new resources with regards to formatting and tests written to validate an expected state. Let me know if you need assistance running them down.

[brandtkeller]

Spent a few cycles digging and found that the problem isn't that there is a difference in the expected values - rather a lack of difference when performing the update-creds operation due to the agent release not being found and no error present in that case.

[brandtkeller]

All checks passing - Believe this is now in a state where we can review the feasibility of the "workaround". I intend to think more about other options that might enable backwards compatibility without needing to keep specific conditional logic.