Fix GoToolV0 to conditionally set GOROOT only for Go < 1.9 (#20796)

[rm-dmiri]

Context

Fix GoToolV0 to conditionally set GOROOT only for Go < 1.9
Fixes: #20796

---

Task Name

GoToolV0

---

Description

The GoToolV0 task was unconditionally setting the GOROOT environment variable for all Go versions. This is problematic because:

1. Go versions >= 1.9 auto-detect GOROOT from the binary location and don't need it set explicitly
2. Setting GOROOT explicitly causes issues when users compile custom Go versions (e.g., Go tip) because:
   • The environment variable overrides the auto-detected GOROOT
   • This creates a mismatch between the go binary and GOROOT
   • Results in errors like "dist doesn't exist" when running go tool dist test

This behavior differs from the GitHub Actions setup-go task, which correctly only sets GOROOT for Go versions < 1.9.

Solution:
Updated the setGoEnvironmentVariables function to:

• Parse the Go version
• Only set GOROOT when the version is < 1.9
• Log debug messages indicating whether GOROOT is being set or skipped
• Continue setting GOPATH and GOBIN as before

---

Risk Assessment (Low / Medium / High)

Low.

---

Change Behind Feature Flag (Yes / No)

No.

---

Tech Design / Approach

Simple change in GOROOT configuration. Conditionally skipped.

---

Documentation Changes Required (Yes/No)

No.

---

Unit Tests Added or Updated (Yes / No)

Yes. Added unit tests.

---

Additional Testing Performed

No.

---

Logging Added/Updated (Yes/No)

• Appropriate log statements are added with meaningful messages.
• Logging does not expose sensitive data.
• Log levels are used correctly (e.g., info, warn, error).

---

Telemetry Added/Updated (Yes/No)

No.

---

Rollback Scenario and Process (Yes/No)

Downgrade task version when using the task.

---

Dependency Impact Assessed and Regression Tested (Yes/No)

• All impacted internal modules, APIs, services, and third-party libraries are analyzed.
• Results are reviewed and confirmed to not break existing functionality.

---

Checklist

• Related issue linked (if applicable)
• Task version was bumped — see versioning guide
• Verified the task behaves as expected

[rm-dmiri]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).