Support for using external Gitlab instead of gitea on zarf init #570
Assignees
Comments
Closed
jeff-mccoy
added a commit
that referenced
this issue
Sep 29, 2022
…754) ## Description This PR introduces the ability to connect to an already existing (and reachable) Container Registry and/or Git Repository during the `zarf init` command. Closes #570 (Support using an external git server) Closes #560 (Support using an external registry) This implementation will serve as a good midway point on having a fully HA in-cluster registry #375. ## PR Feature List - Added several flags to the `init` command to support using an external git repository - Added several flags to the `init` command to support using an external container registry - Update `zarf connect registry` to direct to `{HOST}/v2/_catalog` (this was confusing some other people since it would originally seem like the registry was returning an empty page) - Add utility function to create a tunnel to a service URL - Created slightly better regexp for replacing the host from a `containerImage` url - semi-refactored the `zarf package deploy` logic ## Breaking Changes List - We are changing the structure of the names of repos & containers we are pushing (we are simplifying the name and adding a sha1 hash of the original name to the end of the name) Co-authored-by: Wayne Starr <[email protected]> Co-authored-by: Megamind <[email protected]>
Repository owner
moved this from Doing Now
to Done
in Zarf Project Board
Sep 29, 2022
Closed
Noxsios
pushed a commit
that referenced
this issue
Mar 8, 2023
…754) ## Description This PR introduces the ability to connect to an already existing (and reachable) Container Registry and/or Git Repository during the `zarf init` command. Closes #570 (Support using an external git server) Closes #560 (Support using an external registry) This implementation will serve as a good midway point on having a fully HA in-cluster registry #375. ## PR Feature List - Added several flags to the `init` command to support using an external git repository - Added several flags to the `init` command to support using an external container registry - Update `zarf connect registry` to direct to `{HOST}/v2/_catalog` (this was confusing some other people since it would originally seem like the registry was returning an empty page) - Add utility function to create a tunnel to a service URL - Created slightly better regexp for replacing the host from a `containerImage` url - semi-refactored the `zarf package deploy` logic ## Breaking Changes List - We are changing the structure of the names of repos & containers we are pushing (we are simplifying the name and adding a sha1 hash of the original name to the end of the name) Co-authored-by: Wayne Starr <[email protected]> Co-authored-by: Megamind <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
Similar to #560, it may be desirable for some to use an external Gitlab rather than the internal gitea instance that is shipped with Zarf.
Describe the solution you'd like
In my case specifically my platform has a pre-existing instance of Gitlab that I would like the zarf sync'd code to reside in.
Describe alternatives you've considered
Could configure Gitlab to mirror the gitea instance but I couldn't figure a way to do this in an automated fashion. This work-around still doesn't prevent data duplication.
The text was updated successfully, but these errors were encountered: