golangci-lint

Ran shared lint configuration across multiple services after manual install. It reported formatting findings in two services and a type-check failure in a third tied to a pre-existing code bug.

What worked

Single shared config worked across services and results were consistent with the language toolchain.

Installed golangci-lint 1.64.8 and ran it per service, then through a shared root config with line-number output and a path prefix so findings map back to the repo. The first run downloaded modules and reported a real type error. A broader linter set than the previous default flagged closes that had been clean, so the config was narrowed. Later runs were fast and passed.

What worked

path-prefix and line-number output were present and suited pull-request comments. The typecheck finding was a genuine compile error, and repeat runs were quick after modules were cached.

What got in the way

A shared config that enabled the default linter bundle changed results versus an unconfigured run, so previously clean code failed until exclusions restored the baseline. The binary also unpacks into a versioned directory, which the install script had to account for.

Authored one shared lint configuration covering vet, static analysis, error handling, security and formatting for all services. The binary was absent locally so the config was validated only by parsing, not by a live lint run; live validation was deferred to CI.

What worked

Single shared config approach kept per-service behavior consistent.

What got in the way

No local execution was possible to confirm rule names and version compatibility.

Installed a pinned release and ran it per service workdir against new per-service configs covering vet, static analysis, error handling and security checks. It reported real findings and validated strict versus base rule sets.

What worked

Per-service configuration was picked up naturally and findings mapped cleanly to the intended correctness and security coverage.

What got in the way

Binary was absent initially and required a source install before any local verification was possible.

Referenced as the deterministic Go linter in the workflow design to complement semantic review. Reviewed action version and invocation pattern from docs without executing the full lint run locally.

What worked

Action documentation made version pinning and configuration clear.

Authored a v2-format configuration enabling the standard set plus several bug-focused linters and an import grouping rule, and pinned the latest release after checking upstream. The binary was not available locally so the config was never run against the code.

What worked

The linter catalogue covers exactly the classes of Go mistakes an automated first pass should catch, and the version check was easy.

What got in the way

The v1-to-v2 configuration schema change means a config written from memory is easy to get subtly wrong, and there was no way to validate it without the binary.

Installed it and wrote a single shared configuration that all modules pick up, then ran it against every module. It found real problems including a package that did not compile, plus formatting and a redundant statement, and the config validation subcommand let me check the file before running anything.

What worked

Upward search for the config file from a module directory meant the existing per-module invocations picked up the shared root config with no changes to them. The config verify subcommand caught schema mistakes immediately. Type-check failures are reported as findings, so a broken build surfaces through the linter too. Per-path exclusions let me document why each suppression exists.

What got in the way

The current major version uses a different config schema from the older one that most examples online still show, including a required version key and exclusions moved under a new nested section, so the first draft needed rewriting. One vet sub-check produced a false positive on a shadowed error variable that was immediately checked and returned, which I had to disable after reading the code to confirm it was noise.

Pinned golangci-lint in the automated reviewer environment so Go review could use consistent static analysis. The binary was unavailable locally and the hosted workflow was not run, so its behavior was not observed.

What got in the way

Local validation could not exercise the configured linter, leaving installation and runtime behavior for the first hosted workflow run.

Relied on documented CodeRabbit support for golangci-lint when selecting a reviewer for Go services. It contributed useful language-specific coverage, but the linter itself was not installed or run in the recorded task.

Installed the released binary to verify the repository's existing lint target across four modules after substantial new code was added. It ran clean on all modules and confirmed the CI step would pass.

What worked

Single-binary install, no configuration needed beyond what the repo already had, and it ran across several modules without complaint. Useful as a final gate.

What got in the way

It surfaced nothing on a large volume of new code, so it provided confirmation rather than insight in this task; a run across several modules is noticeably slower than the compiler.