BUILD-11961 Use default Vault URL for Maven Artifactory secrets

[hedinasr]

BUILD-11961 Use default Vault URL for Maven Artifactory secrets

Summary

• Remove the repox-url-based Vault URL override from the Artifactory secret steps in config-maven and build-maven
• Those steps now use the vault-action-wrapper default (vault.sonar.build) instead of switching to vault.dev.sonar.build when targeting the edge/dev Repox URL
• Supports Edge Node + SaaS validation where Artifactory tokens must come from production Vault

Test plan

• Run a Maven build against edge/dev Repox (repox.dev.sonar.build) and confirm Artifactory reader tokens resolve from vault.sonar.build
• Confirm Maven dependency resolution no longer returns 403 for artifacts in sonarsource-qa
• Validate build/promote on sonar-dummy as described in BUILD-11961

---

Summary by Gitar

• Artifactory integration:
  • Added a step to wait for Artifactory token federation sync on edge Repox instances in config-maven/action.yml
• Maven build configuration:
  • Split Maven resolve and deploy Repox URLs with repox-url and repox-deploy-url in build-maven/action.yml
• NPM and UV configurations:
  • Added repox-deploy-url support and removed Vault URL overrides in build-npm/action.yml, config-npm/action.yml, and config-uv/action.yml

_{This will update automatically on new commits.}

[hashicorp-vault-sonar-prod]

BUILD-11961

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

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

See analysis details on SonarQube Cloud

[gitar-bot]

💡 Quality: curl retry lacks connect/max timeout

The polling curl has no --connect-timeout/--max-time, so a hung TCP connection to the edge node would stall an iteration indefinitely rather than counting as a failed attempt, defeating the 5-minute bound. Add --connect-timeout 5 --max-time 15 to keep each attempt time-boxed.

Bound each curl attempt so a stalled connection can't hang the loop.:

http_code="$(curl -sS --connect-timeout 5 --max-time 15 -o /dev/null -w '%{http_code}' \
  -u "${ARTIFACTORY_USERNAME}:${ARTIFACTORY_ACCESS_TOKEN}" \
  "$check_url" || echo "000")"

• Apply fix

_{Check the box to apply the fix or reply for a change | Was this helpful? React with 👍 / 👎}

[gitar-bot]

💡 Quality: curl failure appends duplicate http_code output

On a connection failure curl still emits its -w '%{http_code}' value (000) to stdout, and then || echo "000" appends another, so http_code becomes e.g. 000000, producing confusing log lines like HTTP 000000. Logic still works, but drop the trailing || echo "000" (or capture into a temp and default) so the reported code stays clean.

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

[gitar-bot]

CI failed: YAML syntax error in config-npm/action.yml at line 109 causing GitHub Actions manifest parsing failures across jobs, alongside an unrelated transient GitHub API rate limit error.

Overview

All primary test and build jobs failed due to a consistent YAML syntax error in config-npm/action.yml. One job encountered an intermittent GitHub API rate limit error.

Failures

YAML Syntax Error in Action Manifest (confidence: high)

• Type: configuration
• Affected jobs: 89473496941, 89473331465, 89473331469, 89473331614
• Related to change: yes
• Root cause: A YAML syntax or indentation error at line 109 in config-npm/action.yml prevented the GitHub Actions runner from parsing the action manifest root as a mapping token.
• Suggested fix: Inspect config-npm/action.yml around line 109 and fix the YAML structure/indentation.

GitHub API Rate Limit Exceeded (confidence: high)

• Type: infrastructure
• Affected jobs: 89174884036
• Related to change: unclear
• Root cause: The GitHub installation exceeded its API rate limit (status 403), causing API requests to fail.
• Suggested fix: Wait for the rate limit window to reset or ensure proper authentication tokens are used.

Summary

• Change-related failures: 4 jobs failed due to a configuration/YAML syntax error in config-npm/action.yml.
• Infrastructure/flaky failures: 1 job failed due to a GitHub API rate limit error.
• Recommended action: Fix the YAML syntax error in config-npm/action.yml at line 109.

Code Review 👍 Approved with suggestions 4 resolved / 6 findings

Updates Maven, NPM, and UV actions to use default Vault URLs and adds edge Artifactory token polling, addressing the hardcoded dev ping curl and unconditional 60s sleep findings. Consider adding connect/max timeout to the curl retry and fixing the duplicate http_code output on curl failure.

💡 Quality: curl retry lacks connect/max timeout

📄 shared/wait_artifactory_token_sync.sh:36-38

The polling curl has no --connect-timeout/--max-time, so a hung TCP connection to the edge node would stall an iteration indefinitely rather than counting as a failed attempt, defeating the 5-minute bound. Add --connect-timeout 5 --max-time 15 to keep each attempt time-boxed.

Bound each curl attempt so a stalled connection can't hang the loop.

http_code="$(curl -sS --connect-timeout 5 --max-time 15 -o /dev/null -w '%{http_code}' \
  -u "${ARTIFACTORY_USERNAME}:${ARTIFACTORY_ACCESS_TOKEN}" \
  "$check_url" || echo "000")"

💡 Quality: curl failure appends duplicate http_code output

📄 shared/wait_artifactory_token_sync.sh:36-38

On a connection failure curl still emits its -w '%{http_code}' value (000) to stdout, and then || echo "000" appends another, so http_code becomes e.g. 000000, producing confusing log lines like HTTP 000000. Logic still works, but drop the trailing || echo "000" (or capture into a temp and default) so the reported code stays clean.

✅ 4 resolved

✅ Security: Artifactory token passed on curl command line

📄 config-maven/action.yml:164-166
The Artifactory access token is passed via curl -u "user:token", which exposes the credential in the process argument list (readable via /proc//cmdline by other processes on the runner). Prefer feeding credentials to curl out-of-band, e.g. curl --netrc-file <(printf 'machine %s login %s password %s' "$host" "$ARTIFACTORY_USERNAME" "$ARTIFACTORY_ACCESS_TOKEN") or via -K config from stdin, so the token never appears in the command line.

✅ Quality: Any non-200 response retries for the full 5 minutes

📄 config-maven/action.yml:163-175
The loop only treats HTTP 200 as success and retries every other code for the full 60×5s window before failing. A genuine misconfiguration (e.g. 401 on bad credentials, 404 on wrong URL/repo path) is indistinguishable from the expected federation-lag 403, so a hard failure is delayed by up to 5 minutes with no early feedback. Consider failing fast on non-403/non-2xx codes and only retrying the expected federation-lag codes (403).

✅ Quality: Hardcoded dev ping curl runs for all builds incl. SaaS

📄 config-maven/action.yml:149-154
The added curl to the hardcoded https://repox-internal.dev.sonar.build/artifactory/api/system/ping runs unconditionally before the *jfrog.io* SaaS skip check, so even SaaS/production Repox builds make a request to a fixed dev host that has nothing to do with the actual REPOX_URL. This looks like a leftover debugging probe (verbose -v, output discarded to /dev/null, no effect on control flow). Move it below the SaaS exit and/or remove it, and use $REPOX_URL rather than a hardcoded dev host if the ping is intended to be meaningful.

✅ Performance: Unconditional 60s sleep added to every non-SaaS Maven build

📄 config-maven/action.yml:155-156
Every non-jfrog.io Repox build now blocks for a fixed 60s regardless of whether the token has already federated, adding a full minute to each CI run. This is acknowledged as temporary, but consider polling the ping endpoint until it succeeds (with a timeout cap) instead of a blind fixed sleep to avoid the fixed latency on all edge-node builds.

🤖 Prompt for agents

Code Review: Updates Maven, NPM, and UV actions to use default Vault URLs and adds edge Artifactory token polling, addressing the hardcoded dev ping curl and unconditional 60s sleep findings. Consider adding connect/max timeout to the curl retry and fixing the duplicate http_code output on curl failure.

1. 💡 Quality: curl retry lacks connect/max timeout
   Files: shared/wait_artifactory_token_sync.sh:36-38

   The polling curl has no --connect-timeout/--max-time, so a hung TCP connection to the edge node would stall an iteration indefinitely rather than counting as a failed attempt, defeating the 5-minute bound. Add `--connect-timeout 5 --max-time 15` to keep each attempt time-boxed.

   Fix (Bound each curl attempt so a stalled connection can't hang the loop.):
   http_code="$(curl -sS --connect-timeout 5 --max-time 15 -o /dev/null -w '%{http_code}' \
     -u "${ARTIFACTORY_USERNAME}:${ARTIFACTORY_ACCESS_TOKEN}" \
     "$check_url" || echo "000")"

2. 💡 Quality: curl failure appends duplicate http_code output
   Files: shared/wait_artifactory_token_sync.sh:36-38

   On a connection failure curl still emits its `-w '%{http_code}'` value (000) to stdout, and then `|| echo "000"` appends another, so `http_code` becomes e.g. `000000`, producing confusing log lines like `HTTP 000000`. Logic still works, but drop the trailing `|| echo "000"` (or capture into a temp and default) so the reported code stays clean.

Tip

Comment Gitar fix CI or enable auto-apply: gitar auto-apply:on

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}