Skip to content

ci: bump golangci-lint-action to v9.3.0 and fix DeferMutexUnlock lint offense#3676

Merged
dgageot merged 2 commits into
docker:mainfrom
dgageot:ci/bump-golangci-lint-action-v9.3.0
Jul 16, 2026
Merged

ci: bump golangci-lint-action to v9.3.0 and fix DeferMutexUnlock lint offense#3676
dgageot merged 2 commits into
docker:mainfrom
dgageot:ci/bump-golangci-lint-action-v9.3.0

Conversation

@dgageot

@dgageot dgageot commented Jul 16, 2026

Copy link
Copy Markdown
Member

Bumps golangci/golangci-lint-action from v9.2.0 to v9.3.0 in the CI workflow, with the action SHA pinned to match. golangci-lint itself is already at the latest v2.12.2 so no tool version change was needed.

The bump surfaced a DeferMutexUnlock offense in the scheduler's setRuntime method, where mu.Unlock() was called directly rather than via defer. The fix moves the unlock to a deferred call, which is the safer and idiomatic pattern — it guarantees the lock is released even if a panic occurs, and eliminates the lint warning cleanly.

Additional linters evaluated during this pass (including forcetypeassert, nilerr, nilnil, spancheck, errchkjson, canonicalheader, dupword, musttag, tagalign, godot, gosmopolitan, and others) were not enabled: hits were either false positives, intentional patterns, or stylistic churn with no correctness benefit.

dgageot added 2 commits July 16, 2026 09:36
Assisted-By: docker/claude-sonnet-4-5
@dgageot
dgageot requested a review from a team as a code owner July 16, 2026 07:37

@docker-agent docker-agent 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.

Assessment: 🟢 APPROVE

The changes in this PR are correct and safe.

CI bump (): Straightforward version bump of golangci/golangci-lint-action from v9.2.0 to v9.3.0 with a matching pinned SHA. No correctness concerns.

Mutex fix (pkg/tools/builtin/scheduler/scheduler.go): The setRuntime method's conversion from an explicit t.mu.Unlock() to defer t.mu.Unlock() is safe and idiomatic. The function body contains only the single assignment t.rt = rt, so the effective lock-release point is unchanged. The change is also consistent with the existing runtime() method, which already uses defer t.mu.Unlock(). No deadlock risk — callers invoke signalWake() after setRuntime returns, after the lock is fully released.

No bugs introduced.

@dgageot
dgageot merged commit 53f7603 into docker:main Jul 16, 2026
16 of 19 checks passed
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.

3 participants