fix: set a clear User-Agent for all SonarQube API calls

[okorach-sonar]

Summary

• The migration tool previously sent the Go http.Client default User-Agent (Go-http-client/1.1), making SMT activity hard to distinguish in SonarQube Server/Cloud logs.
• Added a userAgentTransport to the shared transport stack in lib/sq-api-go/client.go (same pattern as the existing authTransport), so every request now sends "User-Agent: sonar-migration-tool".
• This is the only place *http.Client is constructed in the repo; all other request-building code paths reuse sqapi.Client.HTTPClient(), so the fix covers all API traffic.

Fixes #479

Test plan

• go build ./... passes in both lib/sq-api-go and go modules
• go test ./... passes in lib/sq-api-go
• Added TestHTTPClientSetsUserAgent asserting the header is set on outgoing requests

🤖 Generated with Claude Code

[gitar-bot]

💡 Quality: Garbled sentence in buildTransport ordering comment

The comment explaining the transport ordering reads: "because both inject their header by cloning the request and setting it on the clone — a clone debugTransport would never see if it wrapped them from the outside." This sentence is grammatically broken and hard to parse ("a clone debugTransport would never see if it wrapped them"). The intended meaning is that authTransport/userAgentTransport set their headers on a cloned request, so a debugTransport wrapping them from the outside would only ever see the caller's original request and miss the injected Authorization/User-Agent headers. Consider rewording for clarity, e.g. "...set it on the clone — a debugTransport wrapping them from the outside would only see the caller's original request and never the injected headers."

Reword the comment so the rationale reads clearly.:

// authTransport and userAgentTransport sit outside debugTransport (rather
// than the other way around) because both inject their header by cloning
// the request and setting it on the clone — a debugTransport wrapping them
// from the outside would only ever see the caller's original, unmodified
// request and never the injected headers. Retry sits innermost so
// debugTransport still logs exactly once per logical call, using the
// final response after any retries.

_{Was this helpful? React with 👍 / 👎}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[gitar-bot]

Code Review 👍 Approved with suggestions 0 resolved / 1 findings

Injects a specific 'sonar-migration-tool' User-Agent into all API requests to improve auditability in server logs. Consider clarifying the comment in buildTransport to improve readability.

💡 Quality: Garbled sentence in buildTransport ordering comment

📄 lib/sq-api-go/client.go:117-120

The comment explaining the transport ordering reads: "because both inject their header by cloning the request and setting it on the clone — a clone debugTransport would never see if it wrapped them from the outside." This sentence is grammatically broken and hard to parse ("a clone debugTransport would never see if it wrapped them"). The intended meaning is that authTransport/userAgentTransport set their headers on a cloned request, so a debugTransport wrapping them from the outside would only ever see the caller's original request and miss the injected Authorization/User-Agent headers. Consider rewording for clarity, e.g. "...set it on the clone — a debugTransport wrapping them from the outside would only see the caller's original request and never the injected headers."

Reword the comment so the rationale reads clearly.

// authTransport and userAgentTransport sit outside debugTransport (rather
// than the other way around) because both inject their header by cloning
// the request and setting it on the clone — a debugTransport wrapping them
// from the outside would only ever see the caller's original, unmodified
// request and never the injected headers. Retry sits innermost so
// debugTransport still logs exactly once per logical call, using the
// final response after any retries.

🤖 Prompt for agents

Code Review: Injects a specific 'sonar-migration-tool' User-Agent into all API requests to improve auditability in server logs. Consider clarifying the comment in buildTransport to improve readability.

1. 💡 Quality: Garbled sentence in buildTransport ordering comment
   Files: lib/sq-api-go/client.go:117-120

   The comment explaining the transport ordering reads: "because both inject their header by cloning the request and setting it on the clone — a clone debugTransport would never see if it wrapped them from the outside." This sentence is grammatically broken and hard to parse ("a clone debugTransport would never see if it wrapped them"). The intended meaning is that authTransport/userAgentTransport set their headers on a *cloned* request, so a debugTransport wrapping them from the outside would only ever see the caller's original request and miss the injected Authorization/User-Agent headers. Consider rewording for clarity, e.g. "...set it on the clone — a debugTransport wrapping them from the outside would only see the caller's original request and never the injected headers."

   Fix (Reword the comment so the rationale reads clearly.):
   // authTransport and userAgentTransport sit outside debugTransport (rather
   // than the other way around) because both inject their header by cloning
   // the request and setting it on the clone — a debugTransport wrapping them
   // from the outside would only ever see the caller's original, unmodified
   // request and never the injected headers. Retry sits innermost so
   // debugTransport still logs exactly once per logical call, using the
   // final response after any retries.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}