kustomize build {repoUrl}

[monopole]

No description provided.

[rothgar]

I'm assuming this is to have the base yaml files live in a centralized repository and all the customization in the local directory.

I too was curious how remote manifests would work. Maybe store it in the kustomization.yaml file?

[monopole]

This needs some fleshing out.

Say the command

kustomize build git@github.com:someOrg/someRepo.git/{tag}

exists and operates equivalently to

git clone --branch {tag} git@github.com:someOrg/someRepo.git
kustomize build someRepo

Then there's a a win, in that your command history shows that you built your cluster spec from a clear, immutable tag, rather than from a local directory which has who knows what in it.

The repo has to have a kustomization.yaml file at the top level, along with all the resource files it needs, or it the command fails.

To build on this, you modify kustomize more deeply to be able to specify any base or patch as a URI.

[monopole]

The argument to kustomize build and the items in a bases list have the same type - they are both targets. Currently they are just a string that refers to a local directory containing a kustomization.yaml file. A patch could be specified as a URI, but it's not the same type as a target (a patch is just a partial resource file, not a kustomization).

When this is tackled, the solution for build and bases should be the same. Currently the arguments to these things are loaded by a FileLoader, which implements the Loader interface. To treat this string as a github URL with a tag, it might make sense to have a GithubLoader, and a schema detector to decide which loader to use.

Regardless, these two things (built target and base) should have the same target-enhancing solution.