Creating a Zarf package fails on zarf-injector step

[NunoSav]

Environment

Device and OS: macOS 12.5.1 App version: v0.21.2 Kubernetes distro being used: k3s Other:

Steps to reproduce

1. Follow steps at https://docs.zarf.dev/docs/walkthroughs/creating-a-zarf-package

Expected result

Zarf package is created

Actual Result

  ✔  defenseunicorns/zarf-injector:amd64-v0.20.0-31-g4e902fc cosign verified: CLAIMS. TRANSPARENCY LOG (BUNDLED). PUBLIC KEY.
     ERROR:  Unable to copy build/zarf-registry-amd64

Visual Proof (screenshots, videos, text, etc)

Severity/Priority

Additional Context

[jeff-mccoy]

Yeah that's a bit confusing, you don't actually have to build the init package as they are published already on the GitHub release. If you're just testing zarf online following https://zarf.dev/install, the init package will be downloaded on "zarf init".

The actual error your seeing is because there's a prestep for init you have to do to build the secondary go binary. You would use "make init-package ARCH=" where arch is arm64 or amd64. This would create the prerequisite binary for you.

[jeff-mccoy]

@Madeline-UX this may be a deficiency in the docs.

@YrrepNoj what do you think about defining the go build in a prepare script now that we have the capability in zarf?

[Madeline-UX]

@jeff-mccoy I looked at the docs and agree. Here is my assessment of what could be contributed to this error.

• walkthroughs are not segmented by user role or skill level
• Walkthrough does not mention that a Zarf init package is already created and ready to be installed.
• Since package creation will not be part of the end users flow for most users - it probably should not be the first walkthrough on the list (hierarchy issue).

Recommendation

• Look into segmenting walkthroughs based on roles (Package creator or Package deployer)
• Include recommended skill or knowledge level
• Add an admonition to the top of package create that informs users that there are already pre-built supported Init packages >> and link to those in the repo
• Separate package create from Init package create (same process but different use case)
• Consider moving this walk-through into the user guide where we discuss package creation
• Look into reordering walkthroughs with a focus on Jr Sys Admin persona (Package deployer)

This raises a more general question of how might we make the docs work for both user personas while ensuring that the end user doesn't get confused by more advanced capabilities?

[YrrepNoj]

@YrrepNoj what do you think about defining the go build in a prepare script now that we have the capability in zarf?

I'm fine with that.

I know we stopped doing released versions of the injector because they don't update at the same cadence but I would also be happy with making the injector logic it's own project that way we can release the binaries for that instead of hiding the build of them within a Make target.