Support remote zarf.yaml manifests for package creation

[UncleGedd]

Is your feature request related to a problem? Please describe. When engineers create a Zarf package from a zarf.yaml it's important that they are using the version of zarf.yaml that is checked into VCS, not their local copy.

Describe the solution you'd like I'd like to create a zarf package from a remote zarf.yaml, something like zarf package create https://github.com/my-repo/zarf.yaml.

[Racer159]

https://github.com/defenseunicorns/zarf/issues/1091 - linking these since .netrc support may be nice here

[Racer159]

Moving back to milestone v0.26.0 (m3) to allow more time to refactor.

[Racer159]

Clarification on this, likely zarf package create oci://ghcr.io/my-skelly-package:v1.0.0-skeleton would be clearner (since a zarf.yaml is likely to have local files that would be hard to lookup/pull).

Doing this we may also want a zarf package inspect oci://ghcr.io/my-skelly-package:v1.0.0-skeleton.

@UncleGedd would that work for this use case?

[UncleGedd]

I think the original intent was to have remote files in the zarf.yaml so that accidents didn't happen when building a Zarf package locally. I think zarf package create oci://... effectively gets around this concern though. What would the inspect command provide?

[Racer159]

It would allows you to view the zarf.yaml prior to pulling it so that you could see what the package was (since it wouldn't display natively in the registry).

[UncleGedd]

So, I think the original intent of this ticket is now covered by being able to do zarf package deploy oci://... but that inspect command does sound useful. @CollectiveUnicorn do you think you all would use this proposed zarf package inspect oci://... command?

[CollectiveUnicorn]

I think the zarf package deploy oci://... and zarf package inspect oci://... makes sense. We would just need to get those files into an oci repository, where as currently we're just working from our local machines/git.

[Racer159]

To be more clear, right now zarf package deploy oci://... and zarf package inspect oci://... exist for fully built packages (once you publish them).

My understanding was that this issue was for package create so the thought was to enable zarf package create oci://...-skeleton and zarf package inspect oci://...-skeleton with skeleton packages being packages that only include local files and a zarf.yaml to be recombined into other Zarf packages. (you cannot zarf package deploy oci://...-skeleton)

[UncleGedd]

To make sure I'm understanding, the idea is to have a remote Zarf package but it will build packages based on local files? (local files being identified by the -skeleton suffix on the Zarf package). Not sure if CMS would use this workflow. There's a chance this issue is superseded by the ability to deploy from an OCI registry.

[UncleGedd]

I think @CollectiveUnicorn should make the call on this one though

[Racer159]

Yeah the zarf.yaml and any local files that it referenced would get wrapped up in a -skeleton importable package that could be used to build future composed packages.

Lemme know @CollectiveUnicorn if you are good to close this (either superceded by skeletons or OCI deploy which was released)

[CollectiveUnicorn]

As discussed on Slack, I think that between the -skeleton package and OCI deploy, this is taken care of. We just need to work on making use of it on CMS.