[build] Add go mod tidy before go mod vendor for Go 1.24 compat

[rustiqly]

Description

[agent]
Add go mod tidy before go mod vendor in Makefile for Go 1.24 compatibility.

What I did

Added $(GO) mod tidy before the $(GO) mod vendor call in the Makefile.

Why I did it

Go 1.24 (shipped in Debian Trixie) enforces stricter module graph consistency. When go.mod specifies an older Go version but the build runs under Go 1.24, go mod vendor fails with module resolution errors unless go mod tidy runs first.

How I verified it

Successfully built sonic-mgmt-framework under a Trixie slave container with Go 1.24.
On bookworm (Go 1.21), go mod tidy is a no-op — no behavior change.

Type of change

• Bug fix

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Updates the top-level build orchestration to improve Go module vendoring behavior when building sonic-mgmt-framework with newer Go toolchains (notably Go 1.24 in Debian Trixie).

Changes:

• Run go mod tidy before go mod vendor in the $(GO_DEPS) Makefile target to satisfy stricter module-graph consistency requirements in newer Go versions.

[Copilot]

$(GO_DEPS) only depends on go.mod (and codegen init), but the recipe runs go mod tidy/vendor which reads and may update go.sum. If go.sum changes (e.g., via merge/conflict resolution or dependency update) while vendor/.done already exists, make go-deps won’t rerun and vendor/ can become stale relative to go.sum. Consider adding go.sum as an explicit prerequisite (e.g., define GO_SUM=go.sum and include it in the dependency list) so vendoring is rebuilt when checksums change.

[yxieca]

Suggest add version protection like sonic-net/sonic-mgmt-common#207. Otherwise looks good.

[rustiqly]

Good catch — updated to add the same version guard as sonic-mgmt-common #207. Now go mod tidy only runs when the installed Go version is >= the go.mod directive, preventing failures in CI environments with older Go.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[rustiqly]

@yxieca Good suggestion — I'll add Go version protection similar to sonic-mgmt-common#207. Will push an update.

[rustiqly]

@yxieca Actually, looking more closely — the version protection is already in this PR! The guard checks go.mod's Go version against the installed Go version and only runs go mod tidy when Go >= go.mod — exact same pattern as sonic-mgmt-common#207.

The version check block (lines 40-47 in the diff):

@GO_MOD_VER=$$(sed -n 's/^go //p' go.mod) && \
 GO_CUR_VER=$$(\ env GOVERSION | sed 's/go//') && \
 if printf '%s\n' "$$GO_MOD_VER" "$$GO_CUR_VER" | sort -V | head -1 | grep -qx "$$GO_MOD_VER"; then \
   echo "Running go mod tidy"; \
   \ mod tidy; \
 else \
   echo "Skipping go mod tidy"; \
 fi

On bookworm (Go 1.21), it skips tidy. On trixie (Go 1.24), it runs tidy then vendor. Backward compatible either way.

[rustiqly]

@yxieca Thanks for the review! This PR actually already includes the same version guard as sonic-mgmt-common#207 — the sort -V comparison that skips go mod tidy when the installed Go is older than go.mod's directive. You can see it in the diff at lines 40-48 of the Makefile. Let me know if I missed something!

[yxieca]

Thanks for the clarification — you are right, the version guard is already in place. LGTM!

---

This review was posted by an AI agent on behalf of @yxieca.