Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Support Using Zarf With an External Registry and Repository #754

Merged
merged 88 commits into from
Sep 29, 2022

Conversation

YrrepNoj
Copy link
Contributor

@YrrepNoj YrrepNoj commented Sep 20, 2022

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)

@YrrepNoj YrrepNoj force-pushed the 560-external-registry-and-repository branch 2 times, most recently from e97eaca to c1d8b01 Compare September 22, 2022 03:24
If the 'external' git server still exists within the k8s cluster, create a tunnel when pushing repos to it
general cleanup and oranization of functions in hooks package for zarf agent
Makes sure the svc url comes at the end of the provided URL. This captures edge cases where someone has a subdomain that looks just like a service url would. eg) https://svc.cluster.local.example.com
update GitHub workflows to not explicitly create init-package if it's not needed (if it already exists)
The get-admin-password was a bad name because it wasn't clear what 'admin' meant. We are now making the name more explicit
update the flag git-username to git-account and add a note in the usage text to describe what to do if the repository belongs under an org
verify that the git-user and git-password has been provided if using an external git server
give users the ability to set some of the flags for the GitServerInfo without needing to host an extneral repository
ready check now verifies that the zarf-state has been loaded by verifying the distro field has been populated
@jeff-mccoy
Copy link
Contributor

I think we should make testing with code commit and ECR a top priority, without that functionality this PR is far less valuable.

@YrrepNoj
Copy link
Contributor Author

YrrepNoj commented Sep 26, 2022

@RothAndrew @jeff-mccoy

Using ECR ✅ -> Not tested yet but I don't foresee any issues with testing this eventually)

Using CodeCommit 🚫
Zarf needs the ability to 'push to create repo'. This is something supported by Gitea and GitLab but I don't see anything in AWS docs that supports this (and the time I spent playing around didn't bear any good results)

I agree that CodeCommit is probably important enough for us to support as soon as possible, but that will require a bit of a lift in logic and won't be in this PR.

@RothAndrew
Copy link
Contributor

It'll be kinda lame if we have to build in custom support for repo creation per provider, but look at the bright side, maybe we'll actually have a use case that is well suited to using Go's new generics support 😁

@Racer159
Copy link
Contributor

AWS code commit would require other changes than just push to create. It doesn't have a user/org hierarchy by default either:

aws             https://git-codecommit.us-east-1.amazonaws.com/v1/repos/hello-kitteh (fetch)
aws             https://git-codecommit.us-east-1.amazonaws.com/v1/repos/hello-kitteh (push)
bitbucket       https://bitbucket.org/racer159/hello-kitteh (fetch)
bitbucket       https://bitbucket.org/racer159/hello-kitteh (push)
gitlab          https://gitlab.com/Racer159/hello-kitteh (fetch)
gitlab          https://gitlab.com/Racer159/hello-kitteh (push)

@Racer159
Copy link
Contributor

I would be for approving this for now and then having another issue to look at genericizing the provider for git to work with other things like BitBucket and AWS Code Commit.

@YrrepNoj
Copy link
Contributor Author

YrrepNoj commented Sep 26, 2022

@Racer159 I'll work on adding a note to describe the gotchas for using an external repo and registry.

I believe this is ready for another round of reviews in the meantime.

cc @JasonvanBrackel

@Racer159 Racer159 self-requested a review September 28, 2022 19:43
Copy link
Contributor

@Racer159 Racer159 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This worked for my test cases, and generally looks good. I think the only potential gotcha is if GitRepositoryUrls ever change we wouldn't catch the update

@Racer159 Racer159 self-requested a review September 29, 2022 19:53
Racer159
Racer159 previously approved these changes Sep 29, 2022
Copy link
Contributor

@Racer159 Racer159 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@jeff-mccoy jeff-mccoy merged commit eb841ee into master Sep 29, 2022
@bdfinst bdfinst deleted the 560-external-registry-and-repository branch January 12, 2023 22:32
Noxsios pushed a commit that referenced this pull request 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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support for using external Gitlab instead of gitea on zarf init Support external registry on zarf init
4 participants