Kustomize: Kustomize V3+ Reference remote kustomization feature removed?

[Devin-Holland]

In version 2.0.3 before the deprecation of bases you could reference a remote kustomization file like so:

bases:
- git::https://dev.azure.com/myorg/myproject/_git/my-repo.git/some-path

This would pull in the kustomization from that repository and all of the things referenced by that kustomization. Now that I'm moving the line into the resources section it tries to look at my local path instead of a remote repository. Is it intended that you can no longer reference remote kustomization files in V3? Or is there a different way of approaching this?

[Liujingfang1]

@Devin-Holland The remote target can be listed under resources as well. It this doesn't work, it's a bug.

[Devin-Holland]

With this kustomization setup:

resources:
- git::https://dev.azure.com/myorg/myproject/_git/my-repo.git/some-path

@Liujingfang1 It produces this error for me (v3.0.3):

 kustomize build .
Error: accumulating resources: accumulating resources from 'git::https://dev.azure.com/myorg/myproject/_git/my-repo.git/some-path': evalsymlink failure on 'C:\working-project\git::https:\dev.azure.com\myorg\myproject\_git\my-repo.git\some-path' : CreateFile C:\my-repo\git::https:: The filename, directory name, or volume label syntax is incorrect.

Running using version 2.0.3 with that in the bases (as in the comment above) it will output the result of the kustomization from the remote target as expected.

Running using the resources and version 2.1.0 it prompts me for me username and password for dev.azure.com (does not do this in v3.0.0) but the end result is the same error (looking at my local path for the file)

[richardmarshall]

I don't have a repo on azure to test with but the difference in behavior between v2.1.0 and v3.0.0 can be explained by this commit, cc8203032cc12d3a6df21f5d2c51ed3812a39c01, which changed how git urls that contain _git are handled. With that change the git:: prefix is not removed causing the git fetch to fail before getting to an auth attempt.

[Devin-Holland]

This also fails in version 2.1. It's not actually attempting to fetch a remote just checking the local directory for the file. I've tried without git:: as well and that does the same.

[richardmarshall]

Part of what is confusing here is that when an attempt to load the resource via git fails the loader falls back to attempting to load the resource as a file. Since no error information from the git clone attempt is displayed this behavior can make it seem like a clone was never attempted in the first place. It also makes things difficult when trying to diagnose why the clone failed.

In v3.0+ when a git url containing _git/ is parsed the leading git:: is no longer stripped which causes the git binary to fail before getting to the auth portion of the clone. This is why you're seeing slightly different behavior between the two versions.

I think at the very least we should wrap the loader error, in the case that the fallback to file loading also fails, with information that a git clone was attempted and failed. Probably more useful would be some logging from the cloner with the output from the git binary. Would need to include some redaction logic to avoid writing http basic auth credentials in the log output.

[Devin-Holland]

An update on this. You also need to remove the .git after your repository name before the path in your repository with v3.0+ as well as removing git::

bases:
- git::https://dev.azure.com/myorg/myproject/_git/my-repo.git/some-path

becomes

resources:
- https://dev.azure.com/myorg/myproject/_git/my-repo/some-path

I agree that it is very confusing that the error message shows no indication that a pull was ever attempted.

[richardmarshall]

According the the Azure devops documentation the git clone urls for that service are not supposed to include the .git suffix.

https://docs.microsoft.com/en-us/azure/devops/repos/git/clone?view=azure-devops&tabs=command-line#clone-a-repo

So the 2.0.3 behavior of dropping the suffix could arguably be called a bug that enabled an error case to function.

[coderanger]

We are also seeing this, tested with 3.1.0 and 3.2.3. Both try to interpret it as a folder.

[ChrisScottThomas]

I had this problem, due to my remote's being private repos. It would prompt me for credentials, then try and find the folders locally.

I resolved this by switching to ssh instead of ssh:

resources:
- [email protected]:org/my-private-repo

[chrisfowles]

ran into this bug trying to clone private azure repos via ssh on 3.4.0

resources:
  - [email protected]:v3/org_name/project_name/repo_name//folder_name

this will try and clone: [email protected]:v3/org_name/project_name

should clone [email protected]:v3/org_name/project_name/repo_name instead

resources:
  - [email protected]:v3/org_name/project_name/repo_name.git//folder_name

will clone the correct url

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.