Fix golint in CI pipelines of Security Products to lint the entire code trees
Problem to solve
It looks like golint
checks only the projects' root dirs for all Golang projects being developed for Security Products. Code linting is not actually working in pipelines.
See this job as an example of what golint
emits for the common
library when executed correctly.
Intended users
Further details
- There's a relevant addition to the Go guide
- Some work has already been started for the
common
library.
Proposal
-
golint -set_exit_status
command in linting jobs of these projects must be replaced withgolint -set_exit_status $(go list ./... | grep -v "vendor/")
- all linter's complaints for these projects after this change should be addressed
Approach
analyzer projects
For- Add a second linting job with
allow_failure: true
and correctgolint
invocation to this shared config - Fix all
golint
offenses reported by that second job in the analyzers' Go code (one-by-one, see the list) - Wait for all our analyzers are fixed
- Remove second linting job from shared config
- Update the default
go lint
job in shared config with correctgolint
invocation - The End
For any other Go project from Secure section
Perform the same steps as for analyzer projects but in the project's CI config (example).
Projects to update
NOTE: please link the dedicated corresponding merge requests to the items of this list
Common library
Analyzers (SAST)
- bandit gitlab-org/security-products/analyzers/bandit!18 (merged)
- brakeman gitlab-org/security-products/analyzers/brakeman!20 (merged) (todo labels)
- gosec gitlab-org/security-products/analyzers/gosec!29 (merged) (todo labels)
- spotbugs gitlab-org/security-products/analyzers/spotbugs!29 (merged) (todo labels)
- flawfinder gitlab-org/security-products/analyzers/flawfinder!16 (merged) (todo labels)
- kubesec gitlab-org/security-products/analyzers/kubesec!11 (merged)
- phpcs-security-audit gitlab-org/security-products/analyzers/phpcs-security-audit!17 (merged)
- security-code-scan gitlab-org/security-products/analyzers/security-code-scan!25 (merged) (todo labels)
- nodejs-scan gitlab-org/security-products/analyzers/nodejs-scan!30 (merged) (todo labels)
- eslint gitlab-org/security-products/analyzers/eslint!18 (merged) (todo labels)
- tslint gitlab-org/security-products/analyzers/tslint!11 (merged)
- secrets gitlab-org/security-products/analyzers/secrets!35 (merged)
- sobelow gitlab-org/security-products/analyzers/sobelow!15 (merged)
- pmd-apex gitlab-org/security-products/analyzers/pmd-apex!10 (merged)
- kubesec gitlab-org/security-products/analyzers/kubesec!11 (merged)
Analyzers (Dependency Scanning)
- bundler-audit gitlab-org/security-products/analyzers/bundler-audit!34 (merged)
- retire.js gitlab-org/security-products/analyzers/retire.js!31 (merged)
- gemnasium gitlab-org/security-products/analyzers/gemnasium!74 (merged)
- gemnasium-maven gitlab-org/security-products/analyzers/gemnasium-maven!41 (merged)
- gemnasium-python gitlab-org/security-products/analyzers/gemnasium-python!51 (merged)
Standalone Go projects
- sast
- dependency-scanning
- gemnasium-db
- gemnasium-db-toolbox gitlab-org/security-products/gemnasium-db-toolbox!17 (merged)
Documentation
It could be useful to present this to other Go teams across GitLab and include into our Go guidelines.
What does success look like, and how can we measure that?
- All Golang projects in Security Products have their
golint
command fixed in their CI configs- For analyzers - see the proposed approach below
- All linting issues in these projects are addressed
- This fix is documented and presented across GitLab to avoid such hidden linter misbehavior on other Golang projects