k8s-ci-robot
commented
2 years ago @thatsmydoing: This issue is currently awaiting triage.
SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.
The triage/accepted label can be added by org members by writing /triage accepted in a comment.
Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
thatsmydoing
k8s-triage-robot
kustomize's support for URL formats is not well-specified and provides shortcuts for sources like github that do not extend to other repositories and can be cause for confusion. For kustomization v1, I think it would be a good idea to formalize it since it will be a breaking change for other fields as well.
The problems with kustomize's url formats that I see are:
git url extraction
Typically, kustomize manifests live in subdirectories of a repository so a typical url looks like
where the repository to clone is https://github.com/kubernetes-sigs/kustomize and the subdirectory to build is
examples/helloWorld. And kustomize just assumes that the repository is always 2 subdirectories deep. This leads to problems when this isn't the case and more special cases were added that say look one after the _git directory and look for the directory that ends in .git. So we support cloning the following repositories correctly:but https://bitbucket.example.com/scm/project/repository will be treated as clone https://bitbucket.example.com/scm/project and build the subdirectory
repository.I think the better answer here is to just use
//to delimit the repository url and the directory (this is already supported but is still subjected to the above). In that case, there is no need for special cases as we're not guessing anymore. So that https://bitbucket.example.com/scm/project/repository will mean just clone therepositoryrepository and build the root. While https://bitbucket.example.com/scm/project//repository will mean clone theprojectrepository and buildrepositorygo-getter legacy and url magic
kustomize states that it supports "go-getter" format and previously actually did use go-getter (but not always for git cloning). For specifying a repository, all of the following are currently valid for HTTP clones
and the following are valid for SSH clones
and probably a lot more. The logic lives in https://github.com/kubernetes-sigs/kustomize/blob/master/api/internal/git/repospec.go which greatly needs an overhaul.
What's more, most of these only apply to github.com urls, so you can say github.com/kubernetes-sigs/kustomize/examples/helloWorld but bitbucket.com/kubernetes-sigs/kustomize/examples/helloWorld does not. There's also some weird logic with
.gitbeing appended to the repository but not if it's an AWS or Azure code host.I think we should simply restrict the urls to one's accepted by
git clone. Many of the above examples are not valid or wrong. Obviouslygh:andgit::prefixes are not clonable.git clone github.com/kubernetes-sigs/kustomizetries to clone the local directorygithub.com/kubernetes-sigs/kustomizegit clone github.com:kubernetes-sigs/kustomizewill do an SSH clone as your current user but kustomize does an HTTPS onegit clone git@github.com/kubernetes-sigs/kustomizeis not valid as you must use:to delimit host and directorygit clone ssh://git@github.com:kubernetes-sigs/kustomizeis not valid as you must use/to delimit the host and directoryremote resource overlap
kustomize currently tries to load a resource as a "file" first and then as a base. kustomize also supports loading remote file resources via HTTPS so this means it's possible a resource that has
https://can be interpreted as either a file or a base and you'd have to try both to know which is which. This does mean for bases that begin withhttps://, kustomize will try to load it as a file first, then fail, then clone the repository and succeed. This is fine for local files and bases but has some performance penalty for remote files and bases.I'm not really sure what can be done here so long as the formats can overlap. We could say that all remote bases must have a
//. So urls without//are treated as files but those with//are treated as bases. This might be acceptable since I don't believe it's common to havekustomization.yamlat the root of a repository and for those cases we can just say add//or//.to the end. This is a completely breaking change though and can't be eased into like the other suggestions.