Age | Commit message (Collapse) | Author |
|
|
|
Switch all of our tools to use Go v1.19 as minimum Go version. While not
strictly necessary, it makes for a more coherent picture of which Go
version Gitaly uses as a whole.
|
|
|
|
|
|
|
|
|
|
|
|
into 'master'
tools/protolint: Update module github.com/yoheimuta/protolint to v0.41.0
See merge request https://gitlab.com/gitlab-org/gitaly/-/merge_requests/4926
Merged-by: Justin Tobler <jtobler@gitlab.com>
Approved-by: Quang-Minh Nguyen <qmnguyen@gitlab.com>
Approved-by: Justin Tobler <jtobler@gitlab.com>
Co-authored-by: GitLab Renovate Bot <gitlab-bot@gitlab.com>
|
|
|
|
The new tools mechanism is great, this commit just changes the package
name for external tools from `gofumpt` to its own module name, to fix a
small nits from MR#4910.
Signed-off-by: blanet <moweng.xx@alibaba-inc.com>
|
|
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
|