BUILD-12990: Migrate Orchestrator downloads to production Edge

[bwalsh434]

BUILD-12990: Upgrade Orchestrator to 6.4.4.4797 and route its QA distribution downloads and version-alias searches through the production Edge. QA obtains a separate production Edge private-reader token from production Vault and writes a restricted temporary Orchestrator configuration outside caches and artifacts. The test process receives only the configuration URI and home; the token is absent from test JVM properties and reports.

Existing Maven/Gradle/npm dependency configuration retains its endpoints and reader tokens. Publication and promotion remain on SaaS Repox. PR QA uses an isolated temporary Orchestrator home to validate network reads without restored distribution caches; default-branch caches use production-specific keys.

Test plan

• Passed YAML parsing, Bash syntax checks for every changed QA command, and checks that each production Orchestrator job obtains the production reader token and selects a fresh PR home.
• Passed XML parsing for modified Maven manifests (where applicable) and git diff --check.
• Actionlint passes with the existing custom runner labels excluded.
• Verify production reader tokens are absent from test JVM properties and uploaded reports.
• Run existing PR QA on the configured Linux/Windows runners; require uncached private distribution downloads and LATEST_RELEASE or DEV version-alias resolution to succeed.
• Verify deployment/promotion still use SaaS credentials and URLs.

Related library fix: SonarSource/orchestrator#438

[hashicorp-vault-sonar-prod]

BUILD-12990

[gitar-bot]

Code Review ✅ Approved 1 closed / 1 findings

🟡 Medium risk · Routing QA Orchestrator downloads through production Edge using a Vault reader token could expose credentials or disrupt distribution resolution if configuration is mishandled.

Migrates Orchestrator QA downloads and version-alias searches to the production Edge using a temporary, restricted Orchestrator configuration with a fresh home per PR run. Resolved the finding where PR jobs restored and re-saved an unused Orchestrator cache. No open issues remain.

✅ 1 closed

✅ Performance: PR jobs still restore and re-save an Orchestrator cache they never use

📄 .github/actions/orchestrator-cache/action.yml:20-26 📄 .github/workflows/build.yml:116-119 📄 .github/workflows/build.yml:127 📄 .github/workflows/build.yml:236-239 📄 .github/workflows/build.yml:244
On pull_request runs, both QA steps now point ORCHESTRATOR_HOME at ${runner.temp}/orchestrator-production. The orchestrator-cache action still runs on PRs, though. Its only guard is inputs.sq-version != 'DEV'. So it restores the matching orchestrator-production-* cache from the default branch into ${{ github.workspace }}/orchestrator, a directory Maven no longer reads on PRs.

The save key includes github.run_id, so it never matches exactly. Every PR run (4 ruling jobs and 1 plugin job) therefore uploads that unused directory again as a new cache entry. Each job pays for a full download and upload of the Orchestrator distribution for nothing, and the extra entries count toward the repository's cache quota, which can evict caches that are actually used.

Fix: skip the cache action on PRs, e.g. add if: github.event_name != 'pull_request' to the Orchestrator Cache steps in build.yml. Alternatively, add the same condition to the cache step inside the composite action.

Verification Rules 3/3 met

Functional validation No results

Rules 3 passed

✅ Approved GitHub Actions runners
✅ Internal artifact registries
✅ Repository license compliance

Auto-approval Not enabled

Set up

_{For more verification details, comment gitar display:verbose.}

Options

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

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}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube