proper versioning for setup-envtest

[lukas016]

Hi,

we have little problem with kubebuilder which using go install for installation of setup-envtest in latest version.
Using latest version creates unexpected problems with synchronization between developers.

It is possible little optimize and use branch name for installation the same minor version, but if we want to use really the same version, it isn't possible.

Main problem is with go install which requires own tag for every submodule.

go install sigs.k8s.io/controller-runtime/tools/setup-envtest@v0.16.3
go: sigs.k8s.io/controller-runtime/tools/setup-envtest@v0.16.3: module sigs.k8s.io/controller-runtime@v0.16.3 found, but does not contain package sigs.k8s.io/controller-runtime/tools/setup-envtest

Is possible start doing proper version for multimodule repository where tag contains path to submodule too?
Ideally if you create release v0.16.4, you will create tag tools/setup-envtest/v0.16.4 too.

go install github.com/lukas016/controller-runtime/tools/setup-envtest@tools/setup-envtest/v0.16.3
go: finding module for package sigs.k8s.io/controller-runtime/tools/setup-envtest/remote
go: finding module for package sigs.k8s.io/controller-runtime/tools/setup-envtest/workflows
...

[troy0820]

/kind support

[troy0820]

There is a work around for this as main isn't versioned along with tools/setupenv-tools.
#1670 (comment)

I'm not sure the impact of now bundling the new tag you request for setup-envtest to coincide with the controller-runtime's release process. I'm not aware of anything needing to change which why this needs to be hard to coordinate this with the current release process.

[lukas016]

@troy0820 can i ask you why it isn't store in separate repository? I checked https://github.com/kubernetes-sigs/controller-runtime/blob/main/tools/setup-envtest/go.sum and i don't see any dependencies to controller-runtime library. It can be easy manage this tool in separate repo and we can follow standard versioning for golang tools.

[troy0820]

@lukas016 I can't answer that question as I'm not a maintainer of controller-runtime. However, I believe this may have been a side effect of it having it's own go.mod and being embedded in this repository. There are ways to do multimodule version for releases and that may still be an option to satisfy this issue.

[lukas016]

@vincepri can ask you why setup-env is part of this repo and it doesn't have own repo? thx

[lukas016]

@alvaroaleman can we discuss proper versioning of setup-env with separate tags for keep compatibility with go install or maybe other options?

[pmalek]

There is a work around for this as main isn't versioned along with tools/setupenv-tools. #1670 (comment)

I've also hit that issue and the workaround while working it's cumbersome to use. Ideally we'd be able to simply run go install sigs.k8s.io/controller-runtime/tools/setup-envtest@WHATEVER and have setup-envtest installed.

The introduction of tags in the issue description would be a rather cheap way of achieving that (compared to let's say moved the tool to a separate repo and paying the maintenance costs of that).

[Yesphet]

I've encountered the same issue, the method mentioned in this issue regarding tags is very simple and elegant. By synchronously creating the 'tools/setup-envtest/vX.Y.Z' tag, one can easily install it using go install sigs.k8s.io/controller-runtime/tools/setup-envtest@vX.Y.Z
Before such tags are created, a workaround can be utilized via go install sigs.k8s.io/controller-runtime/tools/setup-envtest@BRANCH. For instance go install sigs.k8s.io/controller-runtime/tools/setup-envtest@release-0.15

[sbueringer]

Hey folks,
we are currently experimenting a bit on setup-envtest because the envtest binaries are today hosted on the Google-owned kubebuilder repository.

Going forward we will start hosting the envtest binaries on controller-tools releases. We currently also plan to move setup-envtest to controller-tools as it fits better there. As part of that we will build & publish the setup-envtest binary on controller-tools releases in the future. This should also give proper versioning.

[lukas016]

@sbueringer could you pls keep compatibility with go install? I like this way.