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
AgeCommit message (Collapse)Author
2023-03-15lint: Move custom linter settings to .golangci.yml fileQuang-Minh Nguyen
In a prior change (https://gitlab.com/gitlab-org/gitaly/-/merge_requests/5398), we added the support for custom linters on top of golangci-lint. In the first iteration, all settings for them are put in the implemenation file. This commit moves those settings to the manifeset file, along side with other linter settings. golangci-lint doesn't support an official way to load the settings in de-facto manifest file `.golangci.yml`. Fortunately, we can hook into configuration parsing library `viper` that golangci-lint uses. Our custom linters are loaded at the end, just before executing the commands. At this time, golangci-lint established some state that stores the configuration. This state is process global, and accessible in our source code. In the future, if this approach doesn't work anymore, we can consider parsing the configuration file ourselves.
2023-03-02tools: Fix incompatible dependencies for new Gitaly linterPatrick Steinhardt
In d1c74493a (Add golangci-lint custom linter infrastructure, 2023-02-15), we have added a Gitaly-specific custom linter that is plugged into golangci-lint. For the time being, we agreed to just make it use the same `go.mod` as the main module, mostly because we wanted `make test` to also execute its tests. This is causing problems already, though. The Renovate bot has decided to immediately try and upgrade the new dependency on golang.org/x/tools to the most recent version. But this causes CI failures now because golangci-lint requires all plugins to always use the same version of that package as it uses itself. Fix this by moving the Gitaly-specific linting infrastructure into a subpackage of `tools/golangci-lint` and make it reuse the `go.mod` file. This ensures that they always use compatible versions and that the main production-level `go.mod` file is not tied to a specific dependency version.