fix: migrate source project version per branch instead of hardcoded 1.0.0 (Issue #137)

[okorach-sonar]

Summary

Closes #137.

The source project version (e.g. 3.20) was systematically migrated to SonarCloud as 1.0.0. The fix migrates the real source version, per branch, by querying GET /api/navigation/component?component=<key>&branch=<name> on the source SonarQube and threading the result through to the scanner report uploaded to api/ce/submit.

Why the obvious fix wasn't enough

The version was hardcoded in two places:

1. The sonar.projectVersion form parameter in api/ce/submit.
2. The projectVersion field of the protobuf metadata message embedded inside the scanner-report zip.

SonarCloud's Compute Engine reads the version from the protobuf metadata inside the report — the form parameter is overridden. So fixing only the form parameter still produced 1.0.0. This PR fixes both.

Implementation

• New shared helper src/shared/utils/source-version/resolve-source-project-version.js calls api/navigation/component, returns the version string (trimmed), or null on error / unset / blank value.
  • For main branch: the branch param is omitted, so the source's main-branch version is returned regardless of SQ↔SC main-branch name differences.
  • For non-main branches: branch is passed through (per-branch versions land per-branch on SC).
• Each pipeline (sq-9.9, sq-10.0, sq-10.4, sq-2025) now:
  • Resolves the version once at the entry of transferBranch (the per-branch upload entry point).
  • Threads sourceProjectVersion to transferBranchBatched / uploadReport (for the form parameter).
  • Threads it into the ProtobufBuilder factory options (build-metadata.js reads inst.sourceProjectVersion).
  • Falls back to '1.0.0' if the resolution fails (preserves prior behaviour for unreachable APIs).
• sonarQubeClient is forwarded through transferMainBranch, transferOneBranch / transferSingleBranch, transferNonMainBranches, and the top-level runTransferPhases / executeTransfer so the helper can hit the source API.

Test plan

• Full test suite has identical pass/fail count to main (70 pre-existing failures, 0 new). No regressions.
• Regression test with live SonarQube → SonarCloud per docs/regression-testing.md (verify 3.20 ends up on the SC project, and per-branch versions land on the right branches).

🤖 Generated with Claude Code

---

Note

Medium Risk
Moderate risk because it changes scanner-report metadata and upload parameters across all supported pipeline versions and adds an extra SonarQube API call per branch; failures fall back to the prior 1.0.0 behavior.

Overview
Fixes project version migration by resolving the real SonarQube project version per branch and using it in SonarCloud uploads instead of always sending 1.0.0.

Adds resolveSourceProjectVersion (calls GET /api/navigation/component) and threads sourceProjectVersion through branch transfer flows in sq-9.9, sq-10.0, sq-10.4, and sq-2025, updating both the upload form metadata (version) and the embedded protobuf metadata.projectVersion via ProtobufBuilder options.

^{Reviewed by Cursor Bugbot for commit da6f51d. Bugbot is set up for automated code reviews on this repo. Configure here.}

[sonar-review-alpha]

Summary

This PR fixes Issue #137 where source project versions (e.g. 3.20) were always migrated to SonarCloud as 1.0.0.

The fix introduces a new helper resolveSourceProjectVersion() that queries the source SonarQube's /api/navigation/component endpoint to fetch the real version per branch, then threads it through all four pipeline versions (sq-9.9, sq-10.0, sq-10.4, sq-2025) to both the protobuf metadata and the upload form parameters. Version resolution happens once per branch at the transferBranch() entry point, with fallback to 1.0.0 on error or if the source API is unreachable.

Key detail: The version must be set in both places (protobuf metadata field and form parameter) because SonarCloud's Compute Engine reads from the metadata inside the report zip, not the form parameter. The author's description explains why only fixing one location didn't work.

What reviewers should know

Start here:

• src/shared/utils/source-version/resolve-source-project-version.js — the new helper that does the API call; handles null/undefined/blank versions and API failures gracefully.
• src/pipelines/sq-10.0/transfer-pipeline/helpers/transfer-branch.js — the core entry point showing the full pattern: resolve version once, thread to batched path and non-batched path.

What to check:

• Version threading is consistent across all four pipeline versions (sq-9.9, sq-10.0, sq-10.4, sq-2025). The changes follow the same pattern in each.
• Verify sonarQubeClient is now passed all the way down from runTransferPhases / executeTransfer → transferMainBranch / transferNonMainBranches → transferBranch → into the protobuf builder options.
• Two form parameter locations updated: transfer-branch.js and transfer-branch-batched.js (both set version in the metadata object before uploading).
• Protobuf metadata files (build-metadata.js in each pipeline) now use ctx.sourceProjectVersion || '1.0.0' instead of the hardcoded string.

Known gaps:

• No unit tests added for resolveSourceProjectVersion(). The author has run the existing test suite (70 pre-existing failures, 0 new), but regression testing with a live SonarQube→SonarCloud migration is still marked as TODO.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback