[hedinasr]

BUILD-12158

Summary

Resolving dependencies through the JFrog Edge becomes opt-in. By default nothing changes: every action resolves, deploys and promotes on SaaS Repox.

Operation	Default	Edge opt-in
Resolve (config-*, build-*: Maven mirror, Gradle, npm, pip, uv, Poetry)	repox-url: https://repox.jfrog.io	repox-url: https://repox-internal.dev.sonar.build
Deploy, publish, build info (build-*)	https://repox.jfrog.io	https://repox.jfrog.io
Promote (promote)	https://repox.jfrog.io	https://repox.jfrog.io

• Resolve token follows repox-url: with SaaS, development/artifactory/token/... on vault.sonar.build, as on master. With the Edge, a token issued by the Edge from development/artifactory-edge-dev/token/... on vault.dev.sonar.build (re-terraform-aws-vault#9735).
• Deploy stays on SaaS: repox-deploy-url is removed. The build-* actions always deploy, publish and record build info on https://repox.jfrog.io, with deploy tokens from vault.sonar.build. Gradle resolves through ARTIFACTORY_RESOLVE_URL so its deploy steps can keep ARTIFACTORY_URL on SaaS.
• Promote: always https://repox.jfrog.io; its repox-url input is removed, since the Edge is read-only.
• No more Vault switching on dev.sonar.build for deploy and promote tokens.
• README: new "Resolving through the JFrog Edge" section.

repox-internal.dev.sonar.build is only reachable from runners inside the SonarSource network.

Test plan

• shellspec: 113 examples, 0 failures (build-yarn, build-maven, build-gradle); pre-commit passes.
• sonarcloud-core#11270 pinned to @BUILD-12158 with repox-url: https://repox-internal.dev.sonar.build: dependencies resolve from the Edge with Edge-issued tokens; artifacts deploy and promote on repox.jfrog.io.
• A caller without repox-url resolves from repox.jfrog.io with tokens from vault.sonar.build.

[hashicorp-vault-sonar-prod]

BUILD-12158

[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

[bwalsh434]

LGTM! Discussed with Hedi in our morning sync

[gitar-bot]

Code Review ✅ Approved 8 closed / 8 findings

🔴 High risk · Removing promote’s repox-url input changes a public interface across dependency workflows.

Resolves dependencies through the JFrog Edge as opt-in, with resolve tokens following the selected repox-url while deploy and promote operations stay on SaaS Repox. All findings from this session—including missing README documentation, token engine misconfigurations, and timeout semantics—have been addressed. The intentional default behavior change for Edge pilots is documented; callers must explicitly set repox-url: https://repox.jfrog.io to resolve through SaaS.

✅ 8 closed

✅ Bug: Dropping dev-Vault derivation silently breaks dev/Edge Maven callers

📄 build-maven/action.yml:54-56 📄 build-maven/action.yml:160 📄 config-maven/action.yml:18-20 📄 config-maven/action.yml:101
Previously config-maven/build-maven auto-selected https://vault.dev.sonar.build whenever repox-url contained dev.sonar.build. With the new vault-url input defaulting unconditionally to https://vault.sonar.build, any existing caller that sets repox-url: https://repox.dev.sonar.build (and does not yet know about vault-url) now mints Artifactory tokens from prod Vault against the dev Repox, which fails auth at dependency-resolution/deploy time rather than at config time. The same workflow also becomes internally inconsistent: the ten sibling actions (config-npm, build-npm, config-gradle, build-gradle, config-pip, config-uv, config-poetry, build-poetry, build-yarn, promote) still derive Vault from repox-url, so e.g. build-maven + promote in one dev pipeline would hit two different Vaults. Keeping the derivation as the fallback when vault-url is not explicitly provided preserves current behavior while still allowing the Edge/prod split this PR needs.

✅ Quality: New vault-url input not documented in README input tables

📄 config-maven/action.yml:18-20 📄 build-maven/action.yml:54-56
vault-url is a new public input on both config-maven and build-maven, but the README input tables for those actions (which CONTRIBUTE.md requires to document each action's parameters) were not updated, so callers who need to point Maven at a different Vault have no discoverable documentation. Add a vault-url row to the config-maven table (after repox-url, line 259) and the build-maven table (after repox-url, line 364).

✅ Edge Case: timeout-seconds is not a wall-clock bound; wait can run ~20 minutes

📄 token/index.js:3 📄 token/index.js:23-33 📄 token/index.js:57-71 📄 README.md:83-84
maxAttempts = floor(timeoutSeconds / intervalSeconds) counts only the sleep time. Each probe can also take up to REQUEST_TIMEOUT_MS (30s) before returning status 0, which is retried. With the defaults (300s/10s) and an Edge that hangs, for example an internal host seen from a GitHub-hosted runner, you get 30 × (30s + 10s) ≈ 20 minutes. The README promises "up to 5 minutes", and the final error still says "within 300s". Fix: track a deadline (Date.now() + timeoutSeconds*1000), stop when it passes, and cap each request timeout at the time remaining.

✅ Quality: Probe endpoint differs from the one the PR describes

📄 token/action.yml:11-13 📄 token/index.js:84 📄 config-maven/action.yml:144-150
The PR description says the wait probes com.sonarsource.parent:parent in sonarsource-qa, which is the resolve that failed with 401. The action actually defaults probe-path to api/system/version, and none of the config-* callers override it. So the wait only shows that the Edge accepts the token on a system endpoint. It does not show that this token can read the repository Maven resolves from. Either pass the documented probe path, such as the parent POM under sonarsource-qa, from the config actions, or update the description to match the code.

✅ Quality: build-yarn resolve token not switched to the edge-dev Vault engine

📄 build-yarn/action.yml:136-150
This commit moves the reader (resolve) token in every config-* action to vault.dev.sonar.build / artifactory-edge-dev. build-yarn also resolves through repox-url (the Edge by default) and runs the same token wait, but it still reads its reader token from the default Vault at development/artifactory/token/.... So the pilot tests two different token sources for Edge resolution: yarn builds use the SaaS-federated token and every other ecosystem uses the edge-dev token. Apply the same Vault URL and engine to build-yarn's reader secrets, keeping the deployer token on SaaS Vault in a separate step if needed, or explain why yarn is left out.

...and 3 more closed from earlier reviews

Verification Repos 1 inspected

Functional validation No results

Rules No rules evaluated

Cross-repo 1 repository inspected 0 open impacts

SonarSource/echoes-react Inspected

Auto-approval Not enabled

Set up

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Counting what did not apply, without listing it.

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}