Skip to content

ci(lint): run golangci-lint across the full repo on master push - #4904

Open
Hakai-Shin wants to merge 3 commits into
GoogleCloudPlatform:masterfrom
Hakai-Shin:fix/errcheck-lint-full-repo-2687
Open

ci(lint): run golangci-lint across the full repo on master push#4904
Hakai-Shin wants to merge 3 commits into
GoogleCloudPlatform:masterfrom
Hakai-Shin:fix/errcheck-lint-full-repo-2687

Conversation

@Hakai-Shin

Copy link
Copy Markdown

Summary

  • Fixes Update linter for all Go code #2687: the lint CI job only checked issues on the PR diff (only-new-issues: true), so violations already merged into master were never caught. This PR changes the job so PRs still only check the diff, but pushes to master (post-merge) scan the whole codebase (only-new-issues: false).
  • Fixes the ~216 pre-existing errcheck violations that surfaced once the full-repo scan was run, so the new master job doesn't start out red. Handling falls into three patterns:
    • Real error handling added where dropping the error could mask a bug (temp/cache file cleanup, MRD pool shutdown, GCS reader closes).
    • Best-effort defer/cleanup calls (Close, Remove, RemoveAll, Unmount, Setenv/Unsetenv, os.Stdout writes) explicitly discarded via _ =, since their errors aren't actionable at those call sites.
    • hash.Hash.Write calls discarded, since crypto/*Hash implementations are documented to never return an error.

Known follow-up (needs maintainer input)

Turning on the full-repo scan also surfaces a pre-existing govet/staticcheck/unused/ineffassign backlog that was never caught before (golangci-lint caps reported output at 50 issues/linter by default, so the true count is larger than what any single run shows — roughly 319 govet, mostly from 51 files still importing the deprecated golang.org/x/net/context instead of stdlib context; ~178 staticcheck, mostly style/deprecation nits; a few unused/ineffassign). I deliberately left these out of this PR to keep it scoped to the errcheck issue this ticket describes, but as-is, merging this PR will leave master's Lint job red until that backlog is cleaned up.

Options, happy to go either way:

  1. I open a follow-up PR to clear the rest of the backlog (the x/net/context swap is mechanical; the rest is mostly small style fixes) before/shortly after this merges.
  2. This PR merges as-is and master stays red until a separate cleanup lands — team's call on priority.

Testing details

  1. Manual - Verified on a fork: PR run only lints the diff (passes); pushing to fork's master runs the full-repo scan and correctly reports the pre-existing errcheck backlog is clear (only the known govet/staticcheck/unused items above remain).
  2. Unit tests - Full non-integration test suite (go test across all packages except tools/integration_tests) passes; go build ./... and go vet ./... are clean.
  3. Integration tests - NA (no runtime behavior changed)

Any backward incompatible change? If so, please explain.

No. This only changes CI lint scope/config and error-handling around already-executed cleanup paths; no functional behavior changes.

golangci-lint's errcheck currently only runs against PR diffs, so
these have accumulated undetected across the repo. Fixes span three
patterns:
  - Real handling added where a dropped error could mask a bug
    (temp/cache file cleanup, MRD pool shutdown, GCS reader closes).
  - Best-effort defer/cleanup calls (Close, Remove, RemoveAll, Unmount,
    Setenv/Unsetenv, os.Stdout writes) explicitly discarded via `_ =`,
    since their errors are not actionable at those call sites.
  - hash.Hash.Write calls discarded, since crypto/*Hash implementations
    are documented to never return an error.
Previously the lint job only ran (and only checked new issues) on
pull_request events, so violations in already-merged code were never
caught. Now the job runs on both events, checking only the diff for
PRs (only-new-issues: true) and the whole codebase after merge to
master (only-new-issues: false).
@Hakai-Shin
Hakai-Shin requested review from a team and meet2mky as code owners July 20, 2026 11:12
@Hakai-Shin
Hakai-Shin requested a review from raj-prince July 20, 2026 11:12
@google-cla

google-cla Bot commented Jul 20, 2026

Copy link
Copy Markdown

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Code Review

This pull request systematically addresses unhandled errors across the codebase by explicitly ignoring them using the blank identifier (_), particularly for file closures, removals, and environment variable operations. The reviewer's feedback is highly actionable and should be kept. It suggests explicitly checking write/flush errors on file closures in production code, utilizing the idiomatic t.Setenv helper in tests to simplify environment cleanup, and asserting on Close() errors in tests (especially integration tests where closing triggers GCS flushes) rather than silently discarding them.

Comment thread internal/cache/file/downloader/sparse_downloads_job.go
Comment thread cfg/decode_hook_test.go Outdated
Comment thread internal/util/util_test.go Outdated
Comment thread internal/gcsx/shared_chunk_cache_reader_test.go Outdated
Comment thread tools/proxy_server/config_test.go Outdated
Comment thread tools/integration_tests/rapid_operations/appends_test.go Outdated
- sparse_downloads_job.go: cacheFile is opened for writing, so a Close
  error can mean a flush/disk-full failure; log-and-swallow could
  return success on a corrupted cache file. Explicitly close and check
  the error on the success path, keeping the deferred close only as a
  cleanup guard (mirrors the pattern in SharedChunkCacheReader.downloadChunk).
- cfg/decode_hook_test.go, internal/util/util_test.go: replace manual
  os.Setenv + deferred os.Unsetenv with t.Setenv, which is idiomatic
  (Go 1.17+) and self-cleaning.
- shared_chunk_cache_reader_test.go, config_test.go,
  rapid_operations/appends_test.go: assert Close() succeeds instead of
  discarding the error, since a close failure there (flush/sync to
  GCS, or writing test fixtures) should fail the test rather than be
  silently ignored.
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.

Update linter for all Go code

1 participant