Skip to content
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 stylecheck linter to golangci-lint CI runs #1125

Merged
merged 3 commits into from
Sep 1, 2021

Conversation

dcantah
Copy link
Contributor

@dcantah dcantah commented Aug 24, 2021

This change adds the stylecheck linter to our golangci-lint ci run.
This catches a few nice things like double imports, checking if errors
end with punctuation/aren't capitalized. It also by default checks if
common initialisms (CPU, ID, HTTP, TLS) are in all caps, but this sets off a
metric ton of errors because of the amount of generated schema files we have.
We could exclude these directories from being linted altogether, but would like
to hear what others think. I don't see a way to exclude directories for only certain
checks (so if someone knows a way please do tell)

This change also fixes the issues that the stylecheck linter for golangci-lint
brings up. Most of them are errors starting with a capital letter/ending with
punctuation, but there's two that are for double imports.

In internal/layers/layers.go we were importing the /internal/uvm package twice,
as we used any constants from the package under a package alias of uvmpkg and then
any uses of a pointer to a UtilityVM structt were passed around as uvm. I've changed
the latter to be passed around via vm, as we use this elsewhere in our codebase to store a UtilityVM
object, and then simply replaced umvpkg with the package name itself, uvm.

Signed-off-by: Daniel Canter [email protected]

@dcantah dcantah requested a review from a team as a code owner August 24, 2021 13:39
@dcantah
Copy link
Contributor Author

dcantah commented Aug 24, 2021

fyi @SeanTAllen

@SeanTAllen
Copy link
Contributor

@dcantah awesome.

@katiewasnothere
Copy link
Contributor

Could we have a separate job that runs just the stylecheck linter and that way we can exclude the directories we'd like?

@katiewasnothere
Copy link
Contributor

Alternatively, this example mentions that you can exclude things per linter if I'm reading it correctly.

@dcantah
Copy link
Contributor Author

dcantah commented Aug 24, 2021

@katiewasnothere If that issues section supports regexes, we can exclude anything with s1003 under the schema dirs. That sounds grand to me

@dcantah
Copy link
Contributor Author

dcantah commented Aug 27, 2021

@katiewasnothere That did the trick :). @SeanTAllen About two or three fixes for some of the security policy stuff out of ST1003

This change adds the stylecheck linter to our golangci-lint ci run.
This catches a few nice things like double imports, checking if errors
end with punctuation/aren't capitalized. It also by default checks if
common initialisms (CPU, ID, HTTP, TLS) are in all caps, but this sets off a
metric ton of errors because of the amount of generated schema files we have.
We could exclude these directories from being linted altogether, but would like
to hear what others think. I don't see a way to exclude directories for only certain
checks (so if someone knows a way please do tell)

Signed-off-by: Daniel Canter <[email protected]>
This change fixes the issues that the stylecheck linter for golangci-lint
brings up. Most of them are errors starting with a capital letter/ending with
punctuation, but there's two that are for double imports. Also adds -v to the
golangci-lint args, so it's easier to tell what's going on.

In internal/layers/layers.go we were importing the /internal/uvm package twice,
as we used any constants from the package under a package alias of uvmpkg and then
any uses of a pointer to a UtilityVM object were passed around as `uvm`. I've changed
the latter to be passed around via vm, as we use this elsewhere to store a UtilityVM
object, and then simply replaced umvpkg with the package name itself, uvm.

Signed-off-by: Daniel Canter <[email protected]>
@dcantah dcantah force-pushed the add-stylecheck branch 2 times, most recently from e655ed4 to 5670340 Compare August 27, 2021 14:26
ST1003 checks for if any initialisms don't follow the Go idiom of all capitals.
However, due to this repo having a really high number of packages that have OS
bindings/constants, generated schema files that we generally try and not touch,
and some calls that have been exported and used forever so changing them would
introduce a breaking change, I've taken to excluding some directories from this
specific check. Stylecheck should still check for double imports, and any error
message shenanigans.

This change additionally fixes all of the ST1003 errors in the packages that aren't
excluded.

Signed-off-by: Daniel Canter <[email protected]>
@SeanTAllen
Copy link
Contributor

This is a great PR even if it probably means I'm going to have some merge conflicts.

Copy link
Contributor

@katiewasnothere katiewasnothere left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@@ -12,7 +12,7 @@ import (
const (
hcsComputeSystemSaveType = "AsTemplate"
// default namespace ID used for all template and clone VMs.
DEFAULT_CLONE_NETWORK_NAMESPACE_ID = "89EB8A86-E253-41FD-9800-E6D88EB2E18A"
DefaultCloneNetworkNamespaceID = "89EB8A86-E253-41FD-9800-E6D88EB2E18A"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ambarve Was there a reason this was screaming case? It's not an actual constant from the OS iirc right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ambarve ping

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was no reason to have this in capital case. It is fine to change this.

@ambarve
Copy link
Contributor

ambarve commented Sep 1, 2021

lgtm. Thanks a lot for working on this Danny!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants