You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While looking at the #9758 it seems that linting is actually not working for modules. For example, copying locks should have definitely triggered a CI failure, which it did not.
Most go tools work in a single module boundary and should be executed at every root of go.mod. So, either the script or workflow needs fixing. From github actions output it would probably nice if every single module ended up as a separate result to make the distinction clearer. This probably can even be scoped, such that only changes in a particular module are linted.
I created an proof-of-concept alternative script in egonelbre#1 -- you probably would need to adjust it to fit Google's needs, but it shows how to run go vet, staticcheck modules in parallel and get a nice output in github.
While looking at the #9758 it seems that linting is actually not working for modules. For example, copying locks should have definitely triggered a CI failure, which it did not.
Most go tools work in a single module boundary and should be executed at every root of
go.mod
. So, either the script or workflow needs fixing. From github actions output it would probably nice if every single module ended up as a separate result to make the distinction clearer. This probably can even be scoped, such that only changes in a particular module are linted.Similarly,
golang.org/x/lint/golint
is deprecated and should be replaced withgo vet
. See the notice on https://pkg.go.dev/golang.org/x/lint.The fix for making linting work again is trivial, but it needs a coordinated effort to get all the submodules passing the checks.
The text was updated successfully, but these errors were encountered: