Current Limitation
.github/workflows/pr-builder.yml never touches tools/cli — it only runs go mod download/build/test steps for backend and tests/integration. As a result, tools/cli/go.mod and go.sum can drift out of sync with the actual import graph (e.g. a dependency's // indirect marker going stale after a direct import is added or removed) without any PR check catching it, since nothing in CI ever runs go build, go vet, go test, or go mod tidy against that module.
Suggested Improvement
Add a job (or steps in an existing job) to pr-builder.yml that, for tools/cli:
- runs
go mod tidy and fails the build if it produces a diff (e.g. git diff --exit-code go.mod go.sum after running it), so go.mod/go.sum are always kept accurate and reviewable in the PR diff instead of silently drifting
- runs
go build ./..., go vet ./..., and go test ./... for the module
This mirrors the existing backend/tests/integration Go CI coverage and would have caught the go.mod sync issue found while reviewing #4965.
Current Limitation
.github/workflows/pr-builder.ymlnever touchestools/cli— it only runsgo mod download/build/test steps forbackendandtests/integration. As a result,tools/cli/go.modandgo.sumcan drift out of sync with the actual import graph (e.g. a dependency's// indirectmarker going stale after a direct import is added or removed) without any PR check catching it, since nothing in CI ever runsgo build,go vet,go test, orgo mod tidyagainst that module.Suggested Improvement
Add a job (or steps in an existing job) to
pr-builder.ymlthat, fortools/cli:go mod tidyand fails the build if it produces a diff (e.g.git diff --exit-code go.mod go.sumafter running it), sogo.mod/go.sumare always kept accurate and reviewable in the PR diff instead of silently driftinggo build ./...,go vet ./..., andgo test ./...for the moduleThis mirrors the existing
backend/tests/integrationGo CI coverage and would have caught thego.modsync issue found while reviewing #4965.