Using "zarf package mirror-resources" only pushes to an existing users personal repositories

[shanewhite97]

Environment

Device and OS: Linux Machine pushing to an instance of GitLab
App version: v0.31.1
Kubernetes distro being used: N/A
Other:

Steps to reproduce

1. Create a Zarf package containing only git repositories in the components which will clone the GitLab repository
2. Copy the zarf package to another environment (different domain, offline environment, different GitLab instance etc etc)
3. Run the following command:
   zarf package mirror-resources <your-package.tar.zst>
   --git-url https://<gitlab.domain.tld>
   --git-push-username
   --git-push-password -l trace

Expected result

I expect the cloned repositories to be mirrored into the GitLab instance except for the giturl to be changed..

e.g. https://gitlab.domainA.tld/group/project1
becomes...
https://gitlab.domainB.tld/group/project1

I would expect this to also work if the repo doesn't already exist, that way zarf can be used to just pull across code changes into an offline environment, without necessarily deploying anything.

Actual Result

Zarf only mirrors to repositories located in a users space, and if the repository doesn't exist, it seems like it won't clone it as it says it doesn't exist.

The provided username in the command line becomes the path for the repository, and the zarf url gets a guid added to it, which means the path doesn't match as it did before (this could be renamed to be fair)

Visual Proof (screenshots, videos, text, etc)

Unfortunately this is a protected environment so I had to run a demo version with some redacted information for security, please see below:

Severity/Priority

I would say medium-high, we would love to be able to use zarf to handle packaging as an interim solution for our packaging while we configure the rest of our flux system to be zarf deployment optimised. This functionality seems very restricted for what it could be.

Additional Context

Add any other context or screenshots about the technical debt here.

[Racer159]

@Shane-UE thanks for the issue! This is related to really needing configurability for git repos in general as mentioned in this issue: #1838 - we have looked at likely having a state variable that is similar to what webpack does for filename generation though it has been lower on the priority list for us - will leave this issue open though as this is another use case a feature like this could help.

[schristoff]

Hey, @shanewhite97 - thank you so much for this issue! Wanted to see if you were still running this so we could properly prioritize :) Please let us know

[shanewhite97]

Hi @schristoff! Thanks for following up, we are still using Zarf, but this particular issue isn't uber pressing for us, definitely something we would like at some point!

[dropte]

This is actually very super annoying. It would be so very nice to be able to specify a prefix for both containers (though it seems you can do that by just putting a path at the end of your registry url), and git projects, and then not have zarf mutate your repo names on push.

This is somewhat likely an artifact of how gitlab works as well. You can KIND of get around this by using a group PAT with gitlab. That at least gets it in the right group but you then end up with the arbitrary number stuck on the end of your project/repo.

We have a use case that's basically using Zarf for shuffling content between online and air-gapped repos but we really just want to mirror everything (repos and containers etc) between envs, and not deploy to a cluster or anything with it. Zarf is allllmost perfect for this, but this is basically a dealbreaker without having to write custom scripts to get around this and then lose all the things that zarf does well.

[AustinAbro321]

Not sure if I'm missing anything, but IMO it would be best to implement this change alongside the v1beta1 schema. See - #3433. In the new schema repos could be a list of objects rather than just a list of strings.

The object would be represented in go code as:

type ZarfRepo struct {
	// source git repo
	Source string 
	// The path that the repo will be pushed to. Defaults to the Zarf git-user
	TargetPath string
	// The name the repo will be pushed with. Defaults to the source repo name + crc32hash of the source repo
	TargetName string
}

In practice it would look like

repos:
 - source: https://gitlab.domaina.tld/group/project1
   targetPath: group
   targetName: project1