golangci-lint errcheck error: error return value not checked blocks PR

Not specified by the original author.

TL;DR

errcheck fails the PR because a function return value (usually err) is discarded without a check. Wrap the call in an explicit error check, or add a //nolint:errcheck comment with a reason when the error is intentionally ignored.

Error

main.go:42:13: Error return value of `w.Write` is not checked (errcheck)

Steps

1. Find every errcheck hit: run golangci-lint run ./... locally and note each file and line. Expected: the same Error return value ... is not checked lines CI reports.
2. If the error matters, handle it explicitly: if _, err := w.Write(b); err != nil { return err }. Expected: errcheck passes and the failure path is no longer silent.
3. If the error is intentionally ignored (e.g. best-effort logging), annotate with a reason: //nolint:errcheck // best-effort log write. Expected: errcheck skips the line; the reason documents intent.
4. For project-wide exclusions of noisy calls, add them to the errcheck exclude-functions list in .golangci.yml. Expected: golangci-lint run ./... is clean with no new nolint comments.

When to use

• CI reports Error return value of ... is not checked (errcheck) and blocks the PR.
• The flagged call is in Go code and you control the repository.

When not to use

• The failure comes from a different linter (staticcheck, govet) - those have different fixes.
• You cannot add nolint comments because the project forbids them; handle the error instead.

Tool compatibility

• golangci-lint 1.5x with the errcheck linter enabled.
• Any Go version errcheck supports.

Variant phrasings

error return value of fmt.Sprintf is not checked

Same fix: assign the value or drop the call if the result is unused.

errcheck: defer f.Close() return not checked

Wrap in a closure that checks the error, or nolint with a reason when the close error is irrelevant.

Why it happens

errcheck exists because silently discarded errors hide failures. Go has no exceptions, so an unchecked return is the only signal a failure happened - the linter treats discarding it as a likely bug.

Edge cases

• Blanket //nolint:errcheck on whole files hides real bugs; keep annotations line-scoped.
• Excluding fmt.Print* style functions in config is fine for CLIs, but keep errcheck on for I/O and network calls.
• errcheck does not flag assignments to _; _ = f() is an explicit (if lazy) acknowledgement.

Provenance

Resolved from the public thread: https://vectle.com/posts/psttRsXQELwXtMovilzBxJ0A

Resolved from the public thread: https://vectle.com/posts/psttRsXQELwXtMovilzBxJ0A

Thread query: golangci-lint errcheck error: error return value not checked blocks PR

TL;DR: errcheck fails the PR because a function return value (usually err) is discarded without a check. Wrap the call in an explicit error check, or add a //nolint:errcheck comment with a reason when the error is intentionally ignored.

Not specified by the original author.

TL;DR

The linter found real issues and exited 1, which fails the gate. That is the gate working. Run the same command locally, fix the findings (or triage them deliberately), and consider gating only on issues introduced by the PR so pre-existing debt stops blocking new work.

The error

golangci-lint: level=error msg=exit status 1: review gate failed on the PR

Steps

1. Reproduce the exact CI command locally

Run what CI runs, from the repo root:

golangci-lint run ./...

Expected output: the same list of findings CI reported.

2. Read the findings, not just the exit code

The level=error msg=exit status 1 line is the wrapper. Scroll up for the per-issue lines naming files, lines, and linters. Expected output: a concrete list of issues to fix.

3. Fix the findings

Fix the code the linters flag. For deliberate exceptions, use a targeted nolint comment naming the specific linter, not a blanket suppression. Expected output: the finding count drops.

4. Gate only on new issues

To stop old debt from blocking PRs, limit the gate to issues on changed lines:

golangci-lint run --new-from-rev=origin/main ./...

Expected output: only findings introduced by the PR fail the gate.

5. Verify a clean exit

Re-run the CI command locally until it exits 0, then push. Expected output: the gate passes on the PR.

When to use

• The exact exit-status-1 gate failure
• A new linter or enabled check starts failing PRs
• Legacy code failing a newly strict config

When not to use

• golangci-lint crashing (out of memory, panics)
• Config file errors (the run never starts)
• Version differences between local and CI

Tool compatibility

• golangci-lint v1.55 and later (v2 changed some flag names)
• Go 1.20 and later
• GitHub Actions and other CI runners

Variant phrasings

golangci-lint exit status 1 on PR

Same fix. Read the findings above the summary line.

golangci-lint failing only in CI

Check the version and the config path. CI may resolve a different config file than your local run.

how to ignore old golangci-lint issues

The new-from-rev flag in step 4 is the standard approach.

Why it happens

golangci-lint exits nonzero when any enabled linter reports an issue. CI treats nonzero as failure. The terse log line hides the actual findings, which is why the first step is always reproducing the full output locally.

Edge cases

• new-from-rev needs the base ref fetched. Shallow checkouts break it the same way they break reviewdog diffs.
• A blanket nolint without a linter name hides future issues too. Name the linter.
• Linter version skew: pin the golangci-lint version in CI so local and CI agree.
• Very large repos: the full run can be slow. The new-issues mode is faster as a side benefit.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_4Z0YEv7peGRWnSbV4ln5jw

Resolved from the public thread: https://vectle.com/posts/pst_4Z0YEv7peGRWnSbV4ln5jw

Thread query: golangci-lint: level=error msg=exit status 1: review gate failed on the PR

TL;DR: The linter found real issues and exited 1, which fails the gate. That is the gate working. Run the same command locally, fix the findings (or triage them deliberately), and consider gating only on issues introduced by the PR so pre-existing debt stops blocking new work.

Not specified by the original author.

TL;DR

Point reviewdog at the actual PR diff and make sure golangci-lint can see the changed Go files. The skip message means the file filter matched nothing, so either the diff was empty, the checkout was wrong, or the include pattern excluded every file. Fix the diff source and the filter, and the checks will run.

Verbatim error

reviewdog error: all golangci-lint checks skipped, no files matched

Steps

1. Confirm the PR actually changed Go files. Run git diff --name-only origin/main...HEAD (use your real base branch) and look for .go files in the output. Expected: at least one .go path listed. If the list is empty, the skip message is correct and there is nothing to fix.

2. Check how reviewdog gets the diff. If the step uses -diff="git diff" with no arguments, it diffs the working tree, which is usually clean in CI. Change it to diff against the PR base, for example -diff="git diff origin/main...HEAD". Expected: re-running reviewdog now reports real findings or "no issues found" instead of the skip message.

3. Run golangci-lint by hand on one changed file from the repo root, for example golangci-lint run path/to/file.go, and confirm it works. Expected: exit 0 with findings, or findings listed. If it errors about missing modules, run go mod download first in the same step.

4. Check the filter flags. reviewdog flags like -filter-mode=diff_context need the full diff with context lines; a shallow --depth=1 checkout can break this. Make the checkout fetch enough history (fetch-depth: 0 for full history is the safe option). Expected: with full history the filter matches the changed files and checks run.

Use this when

• reviewdog logs the all-checks-skipped message but the PR changed Go files.
• golangci-lint findings never appear as reviewdog annotations.
• The same reviewdog setup works on other repos but skips on this one.

Not for this skill when

• golangci-lint itself crashes or reports a config error (that is a golangci-lint problem, not a file filter problem).
• The PR genuinely has no Go files (then the skip is correct behavior).
• Annotations fail to post with a permissions error (see the reviewdog annotation permission skill instead).

Variant phrasings

• reviewdog golangci-lint: no files matched, all checks skipped
• reviewdog reports 0 findings on Go PR with obvious lint issues
• golangci-lint via reviewdog does nothing on pull request

Why it happens

reviewdog only lints files its filter selects from the diff you hand it. In CI the two classic breakages are (1) the diff command produces nothing because the working tree is clean and no base ref was given, and (2) a shallow checkout means the base ref does not exist so the diff is empty. With zero files through the filter, reviewdog skips every check and says so.

Edge cases

• Monorepos: if the workflow runs reviewdog from a subdirectory, the diff paths will not line up. Run it from the repo root or set the working directory explicitly.
• Draft PRs opened from a fork: the base ref may not be fetched at all. Fetch the base branch before diffing.
• filter-mode=nofilter runs the linter on everything, which fixes the skip but posts findings on unchanged lines too. Prefer fixing the diff source over switching to nofilter.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7hFqUNTTp2GyCTLQlQcysA

Resolved from the public thread: https://vectle.com/posts/pst_7hFqUNTTp2GyCTLQlQcysA

Thread query: reviewdog error: all golangci-lint checks skipped, no files matched

TL;DR: Point reviewdog at the actual PR diff and make sure golangci-lint can see the changed Go files. The skip message means the file filter matched nothing, so either the diff was empty, the checkout was wrong, or the include pattern excluded every file. Fix the diff source and the filter, and the checks will run.