Create linter step to check code quality #86
Conversation
Helcaraxan
force-pushed
the
feature/ci-mod-tidy
branch
from
0ff81ac to
8775302
Compare
go.mod
Outdated
| @@ -1,17 +1,17 @@ | |||
| module github.com/buildkite/cli | |||
|
|
|||
| go 1.11 | |||
There was a problem hiding this comment.
I imagine the change from go 1.13 (bottom of file) to go 1.11 here is unintentional?
Interestingly, when I run go mod tidy against master using go 1.14, it leaves the go 1.13 line untouched.
I guess go 1.11 is coming from the image: "golang:1.11" being passed to the docker plugin, which does match the version being passed to golang-cross-compile#v1.3.0 for the build.
Maybe I'll sneak in a go 1.14 upgrade which we can rebase this PR onto before merging, so that we don't downgrade go.mod from 1.13 to 1.11 and then back up to 1.14.
There was a problem hiding this comment.
I am not how far you are aware but the go directive in go.mod does not force a specific version of the Go compiler, it simply gives a compatibility indication with respect to the use of features of newer Go releases. As a result this being at 1.11 does not really matter, in many regards.
| @@ -1,5 +1,5 @@ | |||
| #!/bin/bash | |||
| set -euo pipefail | |||
| bash -c "`curl -sL https://raw.githubusercontent.com/buildkite/agent/master/install.sh`" | |||
| bash -c "$(curl -sL https://raw.githubusercontent.com/buildkite/agent/master/install.sh)" | |||
|
Let's merge #88 and then rebase this to get the Go version consistent and up to date. |
|
Thanks @Helcaraxan! |
In order to provide a way to check and maintain code quality over time I am suggestion to add a linter step to the project's CI.
This initial implementation is simply ensuring that the content of the project's
go.modfile is up-to-date and clean. This ensures for example that we are not referencing any unneeded dependencies.Follow-up changes could potentially add some static analysis and other forms of code quality checks.