| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
The viper updates from v1.12.0 onwards breaks backward compatibility.
See https://github.com/spf13/viper/pull/1577. To keep the bot from
updating, let's update the exclude version.
|
|
|
|
tools/golangci-lint: Update module golang.org/x/tools to v0.10.0
See merge request https://gitlab.com/gitlab-org/gitaly/-/merge_requests/5939
Merged-by: John Cai <jcai@gitlab.com>
Approved-by: Justin Tobler <jtobler@gitlab.com>
Approved-by: John Cai <jcai@gitlab.com>
Co-authored-by: GitLab Renovate Bot <gitlab-bot@gitlab.com>
|
|
|
|
|
|
Update golangci-lint to the latest version. This also updates depguard
to the latest version, so we need to modify our config to match the new
version of depguard.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Go plugins are required to be built with the same package versions where
they are being implemented. This change updates `golang.org/x/tools` to
`v0.6.0` so the custom analyzer plugin works with the also updated
version of `golangci-lint`.
|
|
|
|
|
|
|
|
golangci-lint doesn't work with Go 1.17 anymore, since it has
dependencies which set a minimum version of Go 1.18. This breaks `make
lint` locally since the tool errors out during installation.
Update the go.mod to `go 1.18` and run `go mod tidy` in the package.
|
|
The upgrade to Viper v1.13 has introduced a change to lower-case all
config entries in arrays via 5247643 (Recurse into arrays when
converting keys to lowercase, 2022-06-23). This in turn breaks our
ability to pass the `allowTypesBefore` argument to the Revive linter as
it performs an exact match for the arguments.
Let's unblock the upgrade to golangci-lint v1.50.0 by excluding Viper
v1.13 for the time being.
|
|
|
|
Right now we track versions of our Go tooling directly in our Makefile.
While this is simple, it has several drawbacks:
- We're susceptible to supply-chain attacks in case an adversary
manages to replace the code used to build any of our tools.
- We cannot use proper dependencies in our Makefile, which adds the
need for `*.version` files.
- It is hard to build the tools outside of our Makefile as we don't
have a way to properly pull in the correct version.
- Upgrading our tooling requires us to manually hunt down new
releases for all of our tools.
We can fix these issues by following the approach that is efficially
recommended by the Go project [1]: every tool has its own Go module in
`tools/` with a "tool.go" file that imports the tool of interest. Like
this we can use Go's normal tooling to keep track of versions:
- We record hashes of the tool's sources as well as all of its
dependencies, making supply-chain attacks almost impossible.
- We can now provide proper dependencies in our Makefile: every tool
depends on "tool.go", "go.mod" and "go.sum". If any of them
changes we need to rebuild.
- The tools can be installed in the correct version simply by using
`go install` with the correct `go.mod` file.
- Upgrading tools is as simple as running `go get -u`, so no more
manual hunting for new versions.
While these benefits are great on their own already, we can go even
further with this refactoring: now that each tool has its own `go.mod`
file we can adapt the Renovate bot to pick up these files. This means
that we don't have to remember upgrading at all anymore, but instead the
bot will automatically upgrade them for us.
[1]: https://github.com/golang/go/wiki/Modules#how-can-i-track-tool-dependencies-for-a-module
|
