Publish Application Package - Every release

[Madeline-UX]

Is your feature request related to a problem? Please describe. There is currently no application package published with each new release. As a result users have to make/build a zarf package in order to test a deployment into the cluster. This means to get to our desired basic success state for the Zarf user persona (Package Deployer) must also know how to create and build zarf packages, a skill set for the package creator persona.

Describe the solution you'd like I would like Zarf to publish at least one application package with every release - for all supported architectures. To enable users to quickly deploy and use tool in production without learning to make/create.

Proposed Applications for Zarf Packages

• Dos Games
• Kiwix

Additional context I propose that the team decide on which applications we will support for each release and commit to ensuring those are published so that users can download all the files they need from a single source (github repo) to successfully deploy a package without having to learn how to create a package.

Other things to consider:

• [ ] Disable/deprecate sget:// once this occurs and publish this(ese) packages via OCI.
• [ ] There will need to be updates to docs, tutorials and website to support this.
• [x] We also need to determine where this will go (maybe defenseunicorns/zarf maybe defenseunicorns/packages

[Madeline-UX]

@JasonvanBrackel Any thoughts on a way to organize these packages? @YrrepNoj Is there a way to automate their generation for each release?

[Madeline-UX]

This feature would help with usability testing as well. It would allow me to have users to download all packages needed from the github page without me asking a dev to create one.

[jeff-mccoy]

This is not correct, we always build init packages on every release and https://zarf.dev/install has you install an already-built package. Am I missing something?

[jeff-mccoy]

We were considering the user flow. If you publish a package they have to download it manually or include a long sha hash to verify it. The way we do the dos games right now leverages cosign instead so it's still signed but without all the long typing or manual download. I do see value in publishing more packages that way though.

[Madeline-UX]

@jeff-mccoy Yes the init package is already published each release and there is a way using the install to pull the already built package using brew, however, this would allow us to usability test the airgap scenario where we send a user binary + Init + application package to deploy (without someone having to make that package each time) When I asked @YrrepNoj if application packages (ex. dos games) were already published each release he said that they used to be but are not anymore.

[Madeline-UX]

@jeff-mccoy This is a different flow from the connected quick install zarf.dev/install - where we would want to user to download the package.

We still have the quick install though.

[jeff-mccoy]

Okay so they aren't download the files per-se, we are giving them 3 files instead to try "in the airgap"?

[Madeline-UX]

@jeff-mccoy Yes. How those files are accessed, published or organized is up to the team.

[JasonvanBrackel]

Just documenting a conversation between @Madeline-UX, @YrrepNoj, and @Noxsios. We've decided to build the Dos Games and Kiwix packages, and have them in a location accessible to the Zarf Docs and Website like an S3 bucket. I'll let the implementation detail be figured out when it's implementation time.

[Racer159]

This could be something we look into https://www.chainguard.dev/unchained/building-chainguards-container-image-registry

[Madeline-UX]

@Racer159 the idea was so we can have a page on the website for try in air gap that is just two or three files they can grap > transport > and use in airgap

[Racer159]

Moving this back as it is mostly complete just waiting on https://github.com/defenseunicorns/zarf-website/pull/206

[Racer159]

This has been completed