Kustomize unable to build remote base versioned with Git commit

[eliavem]

Hi, I have 2 different repositories, in one I'm storing some overlays and in the other one, I have my base that all overlays use. I am currently versioning my base using the Git SHA1 hash in the commit. For example, I can build on the remote base as:

resources:

• https://github.someOrganization/someName/someRepo.git//base
  ref=7c69acaca930ec40413cfee468d3f2e7af423e20

However, the ref gets ignored. The latest base always is used even if I specify an older commit. Here https://github.com/kubernetes-sigs/kustomize/blob/master/examples/remoteBuild.md#url-format, it is mentioned we can use specific commits and that base will be used. Is this a Bug? I'm currently using kustomize version 3.5.4, but I believe the version should not matter and this behavior should work for any version as specified in the above link. I have tested this locally running "kustomize build" and have also deployed using ArgoCD which uses the same kustomize version. Argo is able to build but the same problem happens. Any help would be appreciated

[ricochet]

Your example should have the ref appended to the url with "?".

For example:

resources:
- git@gitlab.com:someName/k8s-bases.git/bases/golang/?ref=release-0.3
- https://github.someOrganization/someName/someRepo.git//base?ref=7c69acaca930ec40413cfee468d3f2e7af423e20

[eliavem]

@ricochet it was a type in the description, but even with the "?" appended it does not work as expected

[sara4dev]

@eam-cs - it doesn't download the specific sha in v3.5.4. It silently errors out and downloads the master branch always. I had to use the tag or branch to make it pin.

You can find more details here - #2072 (comment)

[mr-karan]

Can confirm even with ?ref=<> the problem is still there.

[michaelgeorgeattard]

In v3.5.4 ?ref=<> works correctly to retrieve tags, in v3.5.5 it does not.

[monopole]

does anyone have a proposed fix?

[Shell32-Natsu]

This issue is introduced in the Git cloning process here.

kustomize/api/internal/git/cloner.go

Line 39 in 9e40cc1

"-b",

In v3.5.4 the implementation was wrong because it reset the repo to FETCH_HEAD after checkout the ref.

But in commit ae458d0, which is included in v3.5.5, it's wrong as well by hard-coding using branch name so commit hash doesn't work.

The fix should be adding a checkout command after cloning.

[Shell32-Natsu]

We cannot use this option as well if we want to support checkout a commit hash.

kustomize/api/internal/git/cloner.go

Line 37 in 9e40cc1

"--depth=1",

[Shell32-Natsu]

Did a deeper research. Kustomize changed to use go-getter but the implementation has a bug. go-getter will try to update the directory if the directory has already existed (hashicorp/go-getter#114).

Kustomize always creates the temporary directory before calling go-getter so the go-getter actually is not used (because the directory is not initialized as a git repo), in most cases I guess. Then the buggy git clone implementation is engaged as a backup mechanism.

I will add a subdirectory in the temporary dir to make go-getter work.

[monopole]

Presumably fixed by #2537. See also #2494

Please see if this can be reproduced in v3.6.1

if so, reopen and add details, thanks!

[mr-karan]

Got the issue in 3.6.1 as well.

Error

Error: accumulating resources: accumulateFile "accumulating resources from 'https://gitlab.xyz/my/repo/?ref=develop':
YAML file [https://gitlab.xyz/my/repo/?ref=develop] encounters a format error.\nerror converting YAML to JSON: yaml: line 3: mapping values are not allowed in thiscontext\n", accumulateDirector: "couldn't make target for path '/tmp/kustomize-440724480/repo':|
unable to find one of 'kustomization.yaml', 'kustomization.yml' or 'Kustomization' in directory '/tmp/kustomize-440724480/repo'"

Version

➜ kustomize version
{Version:kustomize/v3.6.1 GitCommit:c97fa946d576eb6ed559f17f2ac43b3b5a8d5dbd BuildDate:2020-05-27T20:47:35Z GoOs:linux GoArch:amd64}

I can confirm https://gitlab.xyz/my/repo/?ref=develop has kustomization.yaml present in root.
Also kustomize 3.5.4 is the last version where this works correctly.

Don't have the permission to reopen it, but it needs to be @monopole

[Shell32-Natsu]

@mr-karan Currently Kustomize is using go-getter as default method to fetch remote resources. I am not sure whether go-getter has issue with gitlab URL. Can you try to use go-getter to download your repo to see is there an error?

[ricochet]

gitlab URL's are working for me with v3.6.1. Try this format:

resources:
- git@gitlab.com:convoy/my/repo.git/bases/deployment?ref=develop