ci: add native go vet static analysis to validation and release pipelines (#416)#462
Conversation
|
Wondering what really moved? Review this PR in Change Stack to inspect semantic changes, definitions, and references. 📝 WalkthroughWalkthroughCI and release workflows are updated to run ChangesGo vet static analysis in CI workflows
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/ci.yml (1)
21-21:⚠️ Potential issue | 🟠 MajorAlign Go versions between CI and release
ci.ymlsetsgo-version: "1.25"(jobs around lines 21/44/70), butrelease.ymlandgo.moduse Go1.24(go 1.24.2;release.ymlline ~47). This contradicts the “Keep in sync with the go directive in go.mod” comment and can lead to different behavior between CI and release builds. Go 1.25 is an official release, so the main problem is the version mismatch—either align CI togo.mod(e.g.,1.24.2) or document why CI should target1.25.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/ci.yml at line 21, ci.yml currently sets go-version: "1.25" which conflicts with the go directive in go.mod (go 1.24.2) and release.yml; update the CI configuration to match the project Go version or vice versa: either change the go-version field in ci.yml (the go-version key) to the exact version used in go.mod (1.24.2) and release.yml, or update go.mod and release.yml to 1.25 if you intend to move the project to Go 1.25—ensure the change is applied consistently to the go-version key in ci.yml and the go directive in go.mod and release.yml so all three match.
🧹 Nitpick comments (1)
.github/workflows/release.yml (1)
53-54: ⚖️ Poor tradeoffConsider extracting
go vetto a separate job for efficiency.Currently,
go vet ./...runs once for each matrix entry (5 times total). Since static analysis is platform-independent and doesn't depend onGOOS/GOARCH, this is redundant.You could optimize CI resource usage by moving
go vetto a separate job that runs once before the matrix build job, similar to how the CI workflow (.github/workflows/ci.yml) separates test and build jobs.♻️ Example refactor to run go vet once
jobs: + validate: + name: Static Analysis + runs-on: ubuntu-latest + steps: + - name: Checkout code + uses: actions/checkout@v4 + - name: Set up Go + uses: actions/setup-go@v5 + with: + go-version: '1.24' + cache: true + - name: Download dependencies + run: go mod download + - name: Run go vet + run: go vet ./... + build: name: Build & Release (${{ matrix.suffix }}) runs-on: ubuntu-latest + needs: validate strategy: fail-fast: false matrix: # ... existing matrix ... steps: - name: Checkout code uses: actions/checkout@v4 - name: Set up Go uses: actions/setup-go@v5 with: go-version: '1.24' cache: true - name: Download dependencies run: go mod download - - name: Run go vet - run: go vet ./... - name: Build binary # ... rest unchanged ...🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release.yml around lines 53 - 54, Extract the "Run go vet" step (the step with run: go vet ./... and name "Run go vet") out of the matrix job into its own job that runs once (e.g., job "vet"), then make your matrix build job depend on it via needs: vet so the matrix entries only run if vet passes; remove the original "Run go vet" step from the matrix job to avoid duplicate runs and ensure the new vet job uses ubuntu-latest (or any single runner) since vet is platform-independent.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In @.github/workflows/ci.yml:
- Line 21: ci.yml currently sets go-version: "1.25" which conflicts with the go
directive in go.mod (go 1.24.2) and release.yml; update the CI configuration to
match the project Go version or vice versa: either change the go-version field
in ci.yml (the go-version key) to the exact version used in go.mod (1.24.2) and
release.yml, or update go.mod and release.yml to 1.25 if you intend to move the
project to Go 1.25—ensure the change is applied consistently to the go-version
key in ci.yml and the go directive in go.mod and release.yml so all three match.
---
Nitpick comments:
In @.github/workflows/release.yml:
- Around line 53-54: Extract the "Run go vet" step (the step with run: go vet
./... and name "Run go vet") out of the matrix job into its own job that runs
once (e.g., job "vet"), then make your matrix build job depend on it via needs:
vet so the matrix entries only run if vet passes; remove the original "Run go
vet" step from the matrix job to avoid duplicate runs and ensure the new vet job
uses ubuntu-latest (or any single runner) since vet is platform-independent.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 97210391-541c-42ff-8770-c2a0dd71be13
📒 Files selected for processing (2)
.github/workflows/ci.yml.github/workflows/release.yml
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release.yml:
- Around line 18-24: Replace the mutable action tags with immutable commit SHAs
and disable credential persistence: change uses: actions/checkout@v4 to uses:
actions/checkout@<checkout-commit-sha> and add persist-credentials: false under
that step, and change uses: actions/setup-go@v5 to uses:
actions/setup-go@<setup-go-commit-sha> while keeping go-version: '1.24.2' and
cache: true; update the workflow so the checkout step uses persist-credentials:
false and both actions reference their exact commit SHAs (identify them by the
action names actions/checkout and actions/setup-go in the release.yml).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 2f2ef0fb-2534-455e-94ef-2e7b1d998165
📒 Files selected for processing (2)
.github/workflows/ci.yml.github/workflows/release.yml
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/workflows/ci.yml
Contributed as part of GSSoC '26. Optimized pipeline execution metrics and corrected environment versioning mismatches across workflow targets based on static automated feedback loops. 🚀
Problem Description
.github/workflows/ci.yml, the pipeline target environment initialization was pinned to an inaccurate engine runtime ("1.25"), introducing structural drift against the authoritative configuration specified ingo.modand.github/workflows/release.yml(1.24.2)..github/workflows/release.yml, the newly addedgo vet ./...validation step was situated directly within the multi-platform cross-compilation matrix configuration. Because Go's static analysis engine evaluates code syntax abstractly and is strictly platform-independent, executing it across every matrix target resulted in redundant resource utilization and bloated runner billing cycles. Fixes [Feature][CI] Add go vet validation to CI workflow #416.Solution Implemented
go-versionparameters insideci.ymlto target explicit engine uniformity using"1.24.2"..github/workflows/release.ymlby abstractinggo vetcompletely out of the parallelized matrix arrays. Created an isolated, standalonevetjob scheduled on a singular virtual environment instance (ubuntu-latest).needs: [vet]constraint block onto the primary compilation array to guarantee that heavy distributed matrix compilation builds are blocked unless the foundational lint/vet validation check passes cleanly.Verification & Test Logs
go.mod: PASSEDSummary by CodeRabbit