This repo uses several third-party tools like helm, kubectl, golangci-lint, and others which are mostly installed ad hoc. Currently a mix of inline go run/go install, system package managers, and a custom Docker image are used. All(?) of our tools are Go-based, so a more unified approach should be possible.
|
sudo snap install helm --classic |
|
sudo snap install kubectl --classic |
|
HELM ?= "go run helm.sh/helm/v3/cmd/helm@latest" |
|
(cd hack/tools && GOBIN=$(PWD) go install sigs.k8s.io/logtools/logcheck) |
|
RUN go install github.com/gordonklaus/ineffassign@latest && \ |
|
go install github.com/client9/misspell/cmd/misspell@latest |
|
|
|
RUN go install github.com/golangci/golangci-lint/cmd/golangci-lint@v1.52.0 |
|
RUN go install sigs.k8s.io/controller-tools/cmd/controller-gen@v0.20.0 |
|
RUN go install k8s.io/code-generator/cmd/client-gen@v0.36.0 |
Ideally, the pattern we establish here will:
- install tools on-demand at pinned versions
- enable dependabot to automate updates
Go 1.24 introduced the tool directive in go.mod to help with this. We should not use it here. At least not in the way it's meant to be used. Tools in go.mod share dependencies with each other and the rest of the module, so a single version of each module dependency must be compatible with every module that depends on it. This is already the case with the existing set of go.mod dependencies, but the problem is exacerbated when other, independent executables with their own dependency graphs are in the mix. We should be able to build and run those tools with the exact versions of the dependencies that they already compile and test against without affecting our own dependencies compiled into the driver.
One approach I've thought about is to continue to leverage Go modules, but define a separate module for each tool. kubernetes-sigs/dra-driver-topology#5 is one implementation of that idea.
This repo uses several third-party tools like helm, kubectl, golangci-lint, and others which are mostly installed ad hoc. Currently a mix of inline
go run/go install, system package managers, and a custom Docker image are used. All(?) of our tools are Go-based, so a more unified approach should be possible.dra-example-driver/.github/workflows/e2e.yaml
Lines 22 to 23 in a39c14c
dra-example-driver/Makefile
Line 19 in a39c14c
dra-example-driver/Makefile
Line 94 in a39c14c
dra-example-driver/docker/Dockerfile.devel
Lines 17 to 22 in a39c14c
Ideally, the pattern we establish here will:
Go 1.24 introduced the
tooldirective in go.mod to help with this. We should not use it here. At least not in the way it's meant to be used. Tools in go.mod share dependencies with each other and the rest of the module, so a single version of each module dependency must be compatible with every module that depends on it. This is already the case with the existing set of go.mod dependencies, but the problem is exacerbated when other, independent executables with their own dependency graphs are in the mix. We should be able to build and run those tools with the exact versions of the dependencies that they already compile and test against without affecting our own dependencies compiled into the driver.One approach I've thought about is to continue to leverage Go modules, but define a separate module for each tool. kubernetes-sigs/dra-driver-topology#5 is one implementation of that idea.