✅ Deploy Preview for zarf-docs ready!

Name	Link
🔨 Latest commit	a93e6c9
🔍 Latest deploy log	https://app.netlify.com/projects/zarf-docs/deploys/68a38bd430b3c60008cf9760
😎 Deploy Preview	https://deploy-preview-4063--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.

The biggest thing to consider here are workflows that automatically create + push or pull + deploy. This change would break those workflows. That said, I do like this change, and it should be fairly easy for users to figure out what the issue is in their automation. Still, I'd like to here thoughts from other members of @zarf-dev/maintainers.

Codecov Report

✅ All modified and coverable lines are covered by tests.

... and 1 file with indirect coverage changes

It could be a feature flag, that Kit added recently, fancy-names, and then work it in as the default?

While that is an option, I'd rather avoid it. Feature flags have to be documented, maintained, and deprecated. Thinking about the user flows, I'm not sure the better name is convenient enough for me to make sure I have the flag set. Similarly, if I ran into the problem I wouldn't want to disable the feature flag, I'd rather use the new name for my package.

IMO this is a good change for us to make. Two of the same package with different flavors do not necessarily have the same behavior (if so why use a flavor?) so being able to tell which is which and not having them collide on disk feels intuitive. There's lots of breaking changes to consider, many that we may not expect, so as much community feedback as possible on this change is crucial.

Regarding feature flagging it, it would add some amount of safety to making the change where users could undo it. I don't see a lot of value in having it disabled by default to start though. This doesn't necessarily enable new workflows, so keeping it disabled wouldn't get us necessary feedback. This is a good nudge for me to get features into beta with the appropriate website docs and cli support for viewing all flags though!

Two of the same package with different flavors do not necessarily have the same behavior (if so why use a flavor?) so being able to tell which is which and not having them collide on disk feels intuitive.

This is true.... To use the original parent of Zarf, Defense Unicorn, they have two-three flavors, upstream, registry1, and unicorn, where the difference is just the source of the images.

There's lots of breaking changes to consider, many that we may not expect, so as much community feedback as possible on this change is crucial.

This is very true, I can cross post this issue into the slack channel and see what people think as well.

Regarding feature flagging it, it would add some amount of safety to making the change where users could undo it. I don't see a lot of value in having it disabled by default to start though.

I do like the idea of having an on by default feature flag, maybe a little bit of middle ground would be to announce it has a disabled feature with the note saying in N+2 (seems to be about about 1 month for minor version bumps) releases it will be enabled by default. Allowing for A) package maintainers to the required work ahead of time to update the CI/CD logic and B) gives the package maintainers the opportunity to disable it if they can not update either logic for the time being.

This is a good nudge for me to get features into beta with the appropriate website docs and cli support for viewing all flags though!

Ha, yea, I will say it took me a bit to understand the idea behind feature gates, but I think it does open the door for some cool things.

If we as a community decided to go with the feature approach, I would be more then happy to be a bit of a guinea pig with implementing outside of the core maintainers (e.i Austin, Kit, and Brandt).

@a1994sc The default feature flag is definitely a reasonable option, and it's good that the users will be able to control their workflows ahead of time. Ultimately, we'll have to decide if we think users will want to take the extra action ahead of time, and if we want to document it.

I think it'd be good to ask this question in slack and see what people think. Generally Zarf has said that we're okay with breaking changes on create, but really try to avoid breaking changes for deployers. This ride that line a bit since it might break some pull+deploy workflows, but it's always in a non-destructive way so it should be alright.

Just a consideration (this is still useful as is thanks for the PR!) - it could be nice to do zarf-package-<name>-<arch>-<version>-<flavor>.tar.zst (flavor after version) instead to make it easier to map back and forth between OCI registries and tarballs (since that would then just be zarf-package-<last-part-of-repo-name>-<platform-arch>-<tag>.tar.zst without needing to parse/split on the tag to build the package name).

I'm totally fine with that, I can update that this week. Are there any thoughts on the zarf-init change?

Yeah I can see why a user would want to name their packages. I'm not sure I want to special case the name init. Could you create a separate issue for this?

Absolutely, I will create a new issue/pr based off this current PR.

@AustinAbro321 so I removed the custom names for the init packages, however left the flavor indicator in the file name, if that is ok

I mean a lot of both my public and private CI/CD for zarf package using something to the effect of zarf package publish zarf-*.tar.zst so I agree with using the globbing