-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add golangci-lint to CI #154
base: master
Are you sure you want to change the base?
Conversation
34e3983
to
4384c73
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than the 1 comment it LGTM.
I do find it slightly hard, when reading the config file, to tell which options we've changed from the defaults. But on the other hand it is quite useful to have all of the config fields already populated, so I think it's fine.
.golangci.yml
Outdated
new: false | ||
|
||
# Show only new issues created after git revision `origin/master` | ||
new-from-rev: origin/master |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I already use golangci-lint
locally and would prefer for this to not be set locally. Can we use to the --new-from-rev
CLI flag instead?
It'd be really nice if we could target the base branch rather than just origin/master
too, but apparently CircleCI don't give you an env var for that, there's various hacky solutions which people have come up with though...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about this too. I decided to specify it in the config as this would unify the local run with what is in CI, but happy to specify this as a flag in the step instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For me personally it's confusing to not be seeing all linting errors across the project while working in my editor, and feels like it's less likely we'd ever go and clean the project up if this was the case. Happy to get another opinion though.
This change introduces the GolangCI linter into the CI, alongside some sensible defaults for enabled linters. This should help ensure that we are producing high quality code, whilst raising potential issues It is important to note that these configurations are not set in stone, and are likely to change to suit the workflow of the project, enabling or disabling behaviour as seen fit.
This commit neglects to handle or acknowledge the error potentially raised by the ``logger.Log(...)`` call, and so should fail CI.
This reverts commit 0de70df.
This change moves the specification of the diff to check against to the invocation of the command, allowing local runs to run against the entire project. Thanks @benwh.
This change is a test to determine if CI builds are failing due to OOM errors. This should also increase the performance of the linting as the concurrency will match the number of available CPU cores.
4b348f6
to
6cda49c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but it appears to flake due to excessive memory usage :(
We've agreed to take another look after the Kubebuilder upgrade
This change introduces the GolangCI linter into the CI, alongside
some sensible defaults for enabled linters.
This should help ensure that we are producing high quality code,
whilst raising potential issues
It is important to note that these configurations are not set in stone,
and are likely to change to suit the workflow of the project, enabling or
disabling behaviour as seen fit.