-
Notifications
You must be signed in to change notification settings - Fork 601
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
run-checks: added golangci-lint to run-checks #14464
run-checks: added golangci-lint to run-checks #14464
Conversation
0f04f51
to
36f9c0f
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.
Looks good, thanks for working on this! I have a few thoughts/questions about versions of golangci-lint/go which are being used. The only blocker for me is I think we should record an error if the user is not tracking latest/stable
for golangci-lint
in addition to if there's a pending update. And I think maybe we should continue to run golangci-lint
on go 1.18/stable
as well as latest/stable
.
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.
Some more thoughts on synchronization between golangci-lint
version and go
version.
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.
Maybe we should leave our current CI as-is, with the exception of using the golangci-lint
snap instead of the github workflow version.
I'm also a bit wary to turn off golangci-lint
for 1.18/stable
(and leaving it on for latest/stable
) in CI. Afaict new golangci-lint
should remain compatible with old go
versions.
1b18954
to
20217de
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.
Looks really good, thank you! A few final comments. Whether to run golangci-lint
on non-latest/stable
systems is what I'm most concerned about.
run-checks
Outdated
goci_go_ver=$(golangci-lint --version | grep -o 'go[0-9]*\.[0-9]*\.[0-9]*' | cut -c 3-) | ||
go_ver=$(go version | grep -o 'go[0-9]*\.[0-9]*\.[0-9]*' | cut -c 3-) | ||
if [ "$(printf '%s\n' "$go_ver" "$goci_go_ver" | sort -V | head -n1)" != "$go_ver" ]; then | ||
echo "WARNING: Your go version ($go_ver) is greater than the version of go that golangci-lang was built with ($goci_go_ver)." |
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.
echo "WARNING: Your go version ($go_ver) is greater than the version of go that golangci-lang was built with ($goci_go_ver)." | |
echo "WARNING: Your go version ($go_ver) is greater than the version of go that golangci-lint was built with ($goci_go_ver)." |
.github/workflows/test.yaml
Outdated
if [ "${{ matrix.gochannel }}" != "latest/stable" ]; then | ||
export SKIP_GOLANG_CI_LINT=1 | ||
echo "Will skip golangci_lint checks on all but the latest/stable version" |
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.
Sorry to return to this, but I think maybe we should run golangci-lint
regardless of go versions. New golangci-lint
should work with old go versions, so that's not a problem.
The big reason for this though is that if there is a linting error, it will appear as though 1.18/stable
static checks passed and latest/stable
static checks failed, implying that there's a problem with something related to the new version of go, when in reality, it may just be a linting problem caught by golangci-lint
, which happened to only be run on latest/stable
.
So I'd rather remove this check/skip here.
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.
Oops you're right! I forgot to remove that skip after your last comments. Sorry about that.
tests/unit/go/task.yaml
Outdated
# To avoid checking old code, skip golangci-lint | ||
skip="${skip:-} SKIP_GOLANG_CI_LINT=1" | ||
|
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.
If the concern is about checking old code, could we inject a variable with BASE_REF
into these spread tests?
If it's just about not redoing the lint checks on every system, I'd rather adjust the comment to say as much.
FWIW, I think it's probably fine to skip golangci-lint
checks in spread, as this just checks source code and should be system-agnostic. And the spread systems probably don't have the golangci-lint
installed anyway.
.github/workflows/test.yaml
Outdated
@@ -223,6 +212,10 @@ jobs: | |||
export SKIP_GOFMT=1 | |||
echo "Formatting checks will be skipped due to the use of Go version ${{ matrix.gochannel }}" | |||
fi | |||
if [ "${{ matrix.gochannel }}" != "latest/stable" ]; then | |||
export SKIP_GOLANG_CI_LINT=1 |
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.
Super nitpicky nitpick, feel free to ignore: I think SKIP_GOLANGCI_LINT
would be more consistent than SKIP_GOLANG_CI_LINT
, it's already hard enough to remember where the hyphen goes in the binary name :)
…nd made clearer env variable and comment
run-checks
Outdated
if snap refresh --list | grep -q golangci-lint; then | ||
echo "WARNING: your golangci-lint snap is out of date. The CI will install a fresh version, which may differ from yours." | ||
fi | ||
if ! snap list golangci-lint | grep -q latest; then | ||
echo "WARNING: your golangci-lint snap is not installed from the latest/* channel." | ||
fi |
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 suppose those are only relevant iff using golangci-lint from a snap which isn't always the case. Perhaps :
gcil="$(command -v golangci-lint || true)"
if [ -z "$gcil" ]; then
echo "ERROR: Cannot find golangci-lint. You need to first install the golangci-lint"
exit 1
fi
if [ "${gcil/\/snap\/bin/}" != "$gcil" ]; then
# installed from snap
# check refresh
# check latest
fi
# check built-with-go-version etc.
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.
Good point. I added your changes. Thanks!
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.
Thanks for all your work on this, looks really good! Two nitpicks, but neither of them are blockers.
run-checks
Outdated
if ! snap list golangci-lint | grep -q latest; then | ||
echo "WARNING: your golangci-lint snap is not installed from the latest/* channel." | ||
|
||
if [ "${gcil/\/snap\/bin/}" != "$gcil" ]; then |
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.
Nitpick: I'm not familiar with this construction, is this a bash-ism for running a replacement on a variable? If this is bash-specific, I'd stick to POSIX shell and do something a bit more explicit. If this is supported by POSIX-compliant shells then (oh god) it's fine, but I'd still personally prefer something easier to read.
Edit: looks like zsh supports this, but dash doesn't seem to like it:
oac@xps15 ~ foo="hello"
oac@xps15 ~ echo $foo
hello
oac@xps15 ~ echo "${foo/ll/}"
heo
oac@xps15 ~ echo "${foo/ll/aa/}"
heaa/o
oac@xps15 ~ echo "${foo/ll/aa}"
heaao
oac@xps15 ~ dash
$ foo="hello"
$ echo $foo
hello
$ echo "${foo/ll/aa}"
dash: 3: Bad substitution
$ echo "${foo/ll/}"
dash: 4: Bad substitution
Not sure what the takeaway is from this... I think I'd suggest to just do this instead:
if [ "${gcil/\/snap\/bin/}" != "$gcil" ]; then | |
if echo "$gcil" | grep '^\/snap\/bin\/' ; then |
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.
it's likely that ${var/<pattern>/<subst>}
works everywhere but dash
, alternative would be to use:
"${gcil%/snap/bin/golangci-lint}"
which should work in dash too, or:
if echo "$gcil" | grep '/snap/bin/' ; then
(without ^
so that it matches both /snap/bin and /var/lib/snapd/snap/bin)
run-checks
Outdated
fi | ||
goci_go_ver=$(golangci-lint --version | grep -o 'go[0-9]*\.[0-9]*\.[0-9]*' | cut -c 3-) | ||
|
||
# Check whether the version golangci-lint was built with is >= version of go installed |
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.
Nittier nitpick:
# Check whether the version golangci-lint was built with is >= version of go installed | |
# Check whether golangci-lint was built with go version >= the installed go version |
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.
Thanks
Failed tests are: selinux-clean is a known problem |
* run-checks: added golangci-lint run * run-checks: review corrections - remove superfluous exit * run-checks: review corrections * run-checks: added check for go version of golangci-lint and go * tests: added golagnci-lint skip in spread test * run-checks: review corrections - run golangci-lint also on older go and made clearer env variable and comment * run-checks: review corrections - allow for non-snap installation of golangci-lint * run-checks: review corrections
This adds the use of golangci-lint snap both in run-checks.sh and in the CI. The change in the CI's serves to align a local run-checks.sh run with a CI run. By using the same snap and ensuring it's always up to date in both cases, developers should know what the CI is going to tell them before triggering a runner.