Welcome to mirror list, hosted at ThFree Co, Russian Federation.

gitlab.com/gitlab-org/gitaly.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
path: root/tools/goimports
AgeCommit message (Collapse)Author
2023-10-06tools/goimports: Update module golang.org/x/tools to v0.14.0GitLab Renovate Bot
2023-09-05tools/goimports: Update module golang.org/x/tools to v0.13.0GitLab Renovate Bot
2023-08-07tools/goimports: Update module golang.org/x/tools to v0.12.0GitLab Renovate Bot
2023-07-31tools/goimports: Update module golang.org/x/tools to v0.11.1GitLab Renovate Bot
2023-07-21Use Golang 1.20 as minimum required versionNao Hashizume
2023-07-05tools/goimports: Update module golang.org/x/tools to v0.11.0GitLab Renovate Bot
2023-06-16tools/goimports: Update module golang.org/x/tools to v0.10.0GitLab Renovate Bot
2023-06-01tools/goimports: Update module golang.org/x/tools to v0.9.3GitLab Renovate Bot
2023-05-30tools: Switch to Go v1.19 as minimum Go versionPatrick Steinhardt
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.
2023-05-09tools/goimports: Update module golang.org/x/tools to v0.9.1GitLab Renovate Bot
2023-04-13tools/goimports: Update module golang.org/x/tools to v0.8.0GitLab Renovate Bot
2023-03-16tools/goimports: Update module golang.org/x/tools to v0.7.0GitLab Renovate Bot
2023-02-10tools/goimports: Update module golang.org/x/tools to v0.6.0GitLab Renovate Bot
2023-01-09tools/goimports: Update module golang.org/x/tools to v0.5.0GitLab Renovate Bot
2022-12-19tools/goimports: Update module golang.org/x/tools to v0.4.0GitLab Renovate Bot
2022-10-11tools: Keep package name consistent with go.modblanet
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>
2022-10-10Makefile: Track Go tool versions via separate Go modulesPatrick Steinhardt
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
    generated by cgit v1.2.3 (git 2.25.1) at 2024-06-16 16:06:55 +0300