feat: add ability to supply custom init package by a1994sc · Pull Request #4562 · zarf-dev/zarf

a1994sc · 2026-01-28T01:03:07Z

Description

Allow for passing custom init packages to zarf init

Related Issue

Fixes #4560

Checklist before merging

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

Signed-off-by: Allen Conlon <software@conlon.dev>

netlify · 2026-01-28T01:03:13Z

✅ Deploy Preview for zarf-docs canceled.

Name	Link
🔨 Latest commit	`3ff32b5`
🔍 Latest deploy log	https://app.netlify.com/projects/zarf-docs/deploys/698d1adc3b50cd0008286328

a1994sc · 2026-01-28T01:07:47Z

So I wanted to update src/test/e2e/20_zarf_init_test.go to reflect the changes done in this PR...

However I wanted to ask what would be the best way to go about testing it?

Should I first install an older version of zarf, say v0.70.1 with :

zarf init oci://ghcr.io/zarf-dev/packages/init:v0.70.1

Then try to just a:

zarf init

?

codecov · 2026-01-28T01:08:19Z

Codecov Report

❌ Patch coverage is 9.52381% with 19 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/cmd/initialize.go	9.52%	19 Missing ⚠️

Files with missing lines	Coverage Δ
src/cmd/initialize.go	`26.19% <9.52%> (-0.73%)`	⬇️

🚀 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

A few small comments. I think this is a positive change

AustinAbro321 · 2026-02-02T14:31:59Z

@a1994sc I actually have a different request for how you should test this. Could you create a new workflow that tests the previouses release of the init package, deployed with the Zarf binary in the PR? This feature makes it easier for older init package versions to be deployed, so I want to make sure we have a proper test for that.

Signed-off-by: Allen Conlon <software@conlon.dev>

a1994sc · 2026-02-02T16:32:01Z

@a1994sc I actually have a different request for how you should test this. Could you create a new workflow that tests the previouses release of the init package, deployed with the Zarf binary in the PR? This feature makes it easier for older init package versions to be deployed, so I want to make sure we have a proper test for that.

I do think that would be a good idea. Should I create a new one, or update .github/workflows/test-upgrade.yml

To install the latest release, but with the PR binary, and then upgrade?

AustinAbro321 · 2026-02-02T20:41:39Z

hmm I can see the argument both ways. I think test upgrade flow would work if we did:

Deploy old release init package with old release version of Zarf
Deploy old release init package with build version of Zarf from PR
continue with test

The argument against adding it is that it makes our longest job longer, but given that a secondary init is only about a ~45 second increase, I think it'd be fine in test-upgrade.

Signed-off-by: Allen Conlon <software@conlon.dev>

a1994sc · 2026-02-09T01:39:01Z

@AustinAbro321 can you let me know if the changes to .github/workflows/test-upgrade.yml are good for the updated test logic or if you would like me to change anything. Thank you.

Signed-off-by: Allen Conlon <software@conlon.dev>

AustinAbro321 · 2026-02-09T13:00:09Z

      - name: Initialize the cluster with the release version
-        # NOTE: "PATH=$PATH" preserves the default user $PATH. This is needed to maintain the version of zarf installed
-        #       in a previous step. This test run will the current release to create a K3s cluster.
+        # Test will initialize the cluster with the latest released version package, with the current built binary
+        run: |
+          sudo env CI=true ./build/zarf init --components k3s,git-server --nodeport 31337 --confirm ${HOME}/.zarf-cache/zarf-init-amd64-$(zarf version).tar.zst
+
+      - name: Upgrade the cluster with the build version
        run: |
-          sudo env "PATH=$PATH" CI=true zarf init --components k3s,git-server --nodeport 31337 --confirm
+          sudo env CI=true ./build/zarf init --components k3s,git-server --nodeport 31337 --confirm ./build/zarf-init-amd64-$(./build/zarf version).tar.zst


After some more consideration, I actually am going to advocate for a separate workflow to test using the build version of Zarf with the release init package

I don't want to lose the core case we're testing here, which is taking a zarf cluster initialized with version X to version Y. This is the most common use case, so I want to keep it first class within this test, and not risk a situation where it ends up passing, but only because the cluster was first initialized with the build version of Zarf.

From a code clarity perspective should help keep it more clear what each workflow is testing too.

So just for my own understanding, do you like the current flow in .github/workflows/test-upgrade.yml in general? If so, I can work on creating a new workflow based off it

The test upgrade workflow can be a bit confusing I think, but overall it's fine. I don't think we'll need to duplicate the workflow though. I think just proving we can run a build/zarf init using the latest release version of Zarf is enough.

So do you want it to look like this?

sudo env CI=true ./build/zarf init --components k3s,git-server --nodeport 31337 --confirm

That should use the init package in the same folder as build/zarf right?

Yeah the command should mostly look like this, but I'd have it use the last release version of Zarf. Essentially, I'm thinking the command should look like this. We use the build Zarf, but the last release version

sudo env CI=true ./build/zarf init --components k3s,git-server --nodeport 31337 --confirm ${HOME}/.zarf-cache/zarf-init-amd64-$(zarf version).tar.zst

Isn't that what I have on line 76?

Yes, but I'd like it to be outside of the test upgrade workflow.

Right now we're not preforming the test case of release zarf + release zarf init. I don't want to risk there being a difference, between that and build zarf + release zarf init, especially given that using release Zarf to the next version is the the most common flow users will preform when upgrading. I believe having it in a separate workflow also decreases the complexity of this workflow, and makes what we're testing more obvious in both scenarios

Signed-off-by: Allen Conlon <software@conlon.dev>

AustinAbro321

lgtm, nice work

feat: add ability to supply custom init package

fe1d042

Signed-off-by: Allen Conlon <software@conlon.dev>

a1994sc requested review from a team as code owners January 28, 2026 01:03

github-project-automation Bot added this to Zarf Jan 28, 2026

a1994sc self-assigned this Jan 28, 2026

AustinAbro321 requested changes Feb 2, 2026

View reviewed changes

Comment thread site/src/content/docs/commands/zarf_init.md Outdated

Comment thread src/cmd/initialize.go

github-project-automation Bot moved this to In progress in Zarf Feb 2, 2026

chore: address comments per pr

700eeff

Signed-off-by: Allen Conlon <software@conlon.dev>

a1994sc force-pushed the feature/custom-init-package-path branch from 7576424 to 700eeff Compare February 2, 2026 16:20

a1994sc added 6 commits February 8, 2026 15:47

ci: test installing latest release package with local built binary

d2dfa5e

Signed-off-by: Allen Conlon <software@conlon.dev>

ci: fixed variable name

4b5debb

Signed-off-by: Allen Conlon <software@conlon.dev>

ci: update tests for installing package

f757b2f

Signed-off-by: Allen Conlon <software@conlon.dev>

ci: testing version that is not latest

460391f

Signed-off-by: Allen Conlon <software@conlon.dev>

ci: revert to using latest package

0feeefc

Signed-off-by: Allen Conlon <software@conlon.dev>

ci: upgrade to the built version

ca7ca71

Signed-off-by: Allen Conlon <software@conlon.dev>

a1994sc force-pushed the feature/custom-init-package-path branch from de6b900 to ca7ca71 Compare February 9, 2026 01:13

chore: clean up code for review

59f904b

Signed-off-by: Allen Conlon <software@conlon.dev>

a1994sc requested a review from AustinAbro321 February 9, 2026 01:48

AustinAbro321 reviewed Feb 9, 2026

View reviewed changes

a1994sc added 3 commits February 10, 2026 16:36

feat: add custom upgrade version

a685c02

Signed-off-by: Allen Conlon <software@conlon.dev>

Merge branch 'main' into feature/custom-init-package-path

73a7cea

feat: add work flow for version delta

3ff32b5

Signed-off-by: Allen Conlon <software@conlon.dev>

AustinAbro321 approved these changes Feb 12, 2026

View reviewed changes

AustinAbro321 added this pull request to the merge queue Feb 12, 2026

Merged via the queue into main with commit f09b126 Feb 12, 2026
42 checks passed

AustinAbro321 deleted the feature/custom-init-package-path branch February 12, 2026 15:52

github-project-automation Bot moved this from In progress to Done in Zarf Feb 12, 2026

zarf-release-please Bot mentioned this pull request Feb 12, 2026

chore(main): release 0.72.0 #4602

Merged

AustinAbro321 mentioned this pull request Feb 18, 2026

Improve custom init deployment experience #2163

Closed

brandtkeller mentioned this pull request Feb 18, 2026

Download zarf init package automatically (even in noninteractive mode) #1776

Closed

Conversation

a1994sc commented Jan 28, 2026

Description

Related Issue

Checklist before merging

Uh oh!

netlify Bot commented Jan 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for zarf-docs canceled.

Uh oh!

a1994sc commented Jan 28, 2026

Uh oh!

codecov Bot commented Jan 28, 2026 • 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!

Uh oh!

Uh oh!

AustinAbro321 commented Feb 2, 2026

Uh oh!

a1994sc commented Feb 2, 2026

Uh oh!

AustinAbro321 commented Feb 2, 2026

Uh oh!

a1994sc commented Feb 9, 2026

Uh oh!

AustinAbro321 Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

a1994sc Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

AustinAbro321 Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

a1994sc Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

AustinAbro321 Feb 10, 2026

Choose a reason for hiding this comment

Uh oh!

a1994sc Feb 10, 2026 • 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!

AustinAbro321 Feb 10, 2026

Choose a reason for hiding this comment

Uh oh!

AustinAbro321 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

netlify Bot commented Jan 28, 2026 •

edited

Loading

codecov Bot commented Jan 28, 2026 •

edited

Loading

a1994sc Feb 10, 2026 •

edited

Loading