You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Create a Zarf package containing only git repositories in the components which will clone the GitLab repository
Copy the zarf package to another environment (different domain, offline environment, different GitLab instance etc etc)
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..
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.
The text was updated successfully, but these errors were encountered:
@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.
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
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.
The text was updated successfully, but these errors were encountered: