BUILD-11500 Use self-hosted Artifactory for Maven actions

[hedinasr]

BUILD-11500 This PR switches config-maven, build-maven (via config-maven), and promote to the self-hosted JFrog instance at https://repox.dev.sonar.build/artifactory.

Changes

• Remove repox-url and repox-artifactory-url inputs from config-maven, build-maven, and promote.
• Set ARTIFACTORY_URL to https://repox.dev.sonar.build/artifactory in the composite action steps (not configurable).
• Keep Vault for Artifactory credentials (private-reader / public-reader, deployer, promoter) and document the fixed URL in the README.

Breaking changes

• Workflows that pass repox-url or repox-artifactory-url to config-maven, build-maven, or promote must drop those inputs.

Other actions (config-gradle, config-pip, build-npm, etc.) still use repox-* URL inputs and are unchanged in this PR.

Prerequisites (Platform)

• Vault development/artifactory mount must reach repox.dev.sonar.build and issue tokens valid for that instance.
• Repository Vault roles (*-reader, *-qa-deployer, *-promoter, etc.) must exist for the new instance as needed.

Test plan

• config-maven on a sample repo resolves dependencies from repox.dev.sonar.build.
• build-maven build and deploy still work end-to-end.
• promote promotes a build against the same instance.

---

Summary by Gitar

• Action configuration:
  • Removed repox-url and repox-artifactory-url inputs from config-maven, build-maven, and promote actions.
  • Hardcoded ARTIFACTORY_URL to https://repox.dev.sonar.build/artifactory across core Maven actions.
• Documentation updates:
  • Updated README.md to note contents: read permission requirements and added Vault access details for develocity.
  • Clarified that Maven dependencies now resolve exclusively from the self-hosted instance.

_{This will update automatically on new commits.}

[hashicorp-vault-sonar-prod]

BUILD-11500

[gitar-bot]

⚠️ Quality: updatePolicy=always contradicts adjacent comment and adds overhead

In the plugin releases repository, updatePolicy was changed from interval:60 to always, but the comment directly above it still reads: "no need to always check if new versions are available when executing a Maven plugin without specifying the version". The code now does the exact opposite of what the comment states.

Functionally, always makes Maven check the remote repository for plugin updates on every single build. For a release (non-snapshot) plugin repository this is almost never desired — released artifacts are immutable, so the only effect is added network round-trips (and slower, less reliable builds) on each invocation. interval:60 (or daily) already balanced freshness against performance.

Suggested fix: either revert to interval:60/daily, or if always is intentional, update the comment to explain why frequent checks are now required. Note the <releases> repository block above (line 48) still uses interval:60, so this also introduces an inconsistency between the two repository definitions.

Revert to interval:60 to match the comment and the releases repository above.:

<releases>
  <enabled>true</enabled>
  <!-- no need to always check if new versions are available when executing a Maven plugin without specifying the version -->
  <updatePolicy>interval:60</updatePolicy>
  <checksumPolicy>fail</checksumPolicy>
</releases>

• Apply fix

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

[gitar-bot]

💡 Edge Case: artifactory vault step may emit empty output for non-deploy builds

The new artifactory step requests zero secrets when inputs.deploy == 'false' (all three secret lines evaluate to ''), and it has no if: guard, so it always runs. Lines 190-192 then call fromJSON(steps.artifactory.outputs.vault).ARTIFACTORY_DEPLOY_USERNAME etc.

Previously these deploy credentials lived in the secrets step, whose output was always non-empty valid JSON because it also requested SIGN_KEY/PGP_PASSPHRASE. Now, for non-deploy builds (e.g. PR builds with deploy=false), the dedicated artifactory step may produce an empty vault output. If the wrapper emits '' rather than {} in that case, fromJSON('') would throw and fail the env evaluation of the build step for all non-deploy runs.

Please confirm vault-action-wrapper outputs {} (not empty string) when no secrets are requested; if not, add an if: guard on the artifactory step (e.g. only when deploy != 'false') and gate the dependent env vars accordingly.

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

[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]

Code Review ⚠️ Changes requested 1 resolved / 3 findings

Migrates Maven actions to the self-hosted Artifactory instance while removing configurable URL inputs. The updatePolicy set to 'always' contradicts the existing configuration comment, and the vault step may incorrectly emit empty output for non-deploy builds.

⚠️ Quality: updatePolicy=always contradicts adjacent comment and adds overhead

📄 config-maven/resources/settings.xml:62-66

In the plugin releases repository, updatePolicy was changed from interval:60 to always, but the comment directly above it still reads: "no need to always check if new versions are available when executing a Maven plugin without specifying the version". The code now does the exact opposite of what the comment states.

Functionally, always makes Maven check the remote repository for plugin updates on every single build. For a release (non-snapshot) plugin repository this is almost never desired — released artifacts are immutable, so the only effect is added network round-trips (and slower, less reliable builds) on each invocation. interval:60 (or daily) already balanced freshness against performance.

Suggested fix: either revert to interval:60/daily, or if always is intentional, update the comment to explain why frequent checks are now required. Note the <releases> repository block above (line 48) still uses interval:60, so this also introduces an inconsistency between the two repository definitions.

Revert to interval:60 to match the comment and the releases repository above.

<releases>
  <enabled>true</enabled>
  <!-- no need to always check if new versions are available when executing a Maven plugin without specifying the version -->
  <updatePolicy>interval:60</updatePolicy>
  <checksumPolicy>fail</checksumPolicy>
</releases>

💡 Edge Case: artifactory vault step may emit empty output for non-deploy builds

📄 build-maven/action.yml:146-154 📄 build-maven/action.yml:190-192

The new artifactory step requests zero secrets when inputs.deploy == 'false' (all three secret lines evaluate to ''), and it has no if: guard, so it always runs. Lines 190-192 then call fromJSON(steps.artifactory.outputs.vault).ARTIFACTORY_DEPLOY_USERNAME etc.

Previously these deploy credentials lived in the secrets step, whose output was always non-empty valid JSON because it also requested SIGN_KEY/PGP_PASSPHRASE. Now, for non-deploy builds (e.g. PR builds with deploy=false), the dedicated artifactory step may produce an empty vault output. If the wrapper emits '' rather than {} in that case, fromJSON('') would throw and fail the env evaluation of the build step for all non-deploy runs.

Please confirm vault-action-wrapper outputs {} (not empty string) when no secrets are requested; if not, add an if: guard on the artifactory step (e.g. only when deploy != 'false') and gate the dependent env vars accordingly.

✅ 1 resolved

✅ Bug: secrets vault step lost url override after split

📄 build-maven/action.yml:146-160
When the Artifactory credential secrets were split out into the new artifactory vault step (lines 146-154), the url: https://vault.dev.sonar.build override was carried only to that new step. The original secrets step (lines 156-169) now has no url: input, so it falls back to the vault-action-wrapper default URL, while the adjacent artifactory step explicitly targets vault.dev.sonar.build.

If the wrapper's default URL is not the same instance, the two adjacent steps will resolve against different Vault instances within the same action run: Artifactory deploy credentials from vault.dev.sonar.build, but NEXT_TOKEN / SQC tokens / SIGN_KEY / PGP_PASSPHRASE from the default vault. That mismatch can break signing and analysis, or fetch the wrong secrets, on this branch. The combined step previously had a single url: https://vault.dev.sonar.build covering all of these secrets.

Suggested fix: set url: https://vault.dev.sonar.build on the secrets step as well (or remove it from both if the default is intended), so both steps consistently target the same Vault instance.

🤖 Prompt for agents

Code Review: Migrates Maven actions to the self-hosted Artifactory instance while removing configurable URL inputs. The updatePolicy set to 'always' contradicts the existing configuration comment, and the vault step may incorrectly emit empty output for non-deploy builds.

1. ⚠️ Quality: updatePolicy=always contradicts adjacent comment and adds overhead
   Files: config-maven/resources/settings.xml:62-66

   In the plugin releases repository, `updatePolicy` was changed from `interval:60` to `always`, but the comment directly above it still reads: "no need to always check if new versions are available when executing a Maven plugin without specifying the version". The code now does the exact opposite of what the comment states.
   
   Functionally, `always` makes Maven check the remote repository for plugin updates on every single build. For a *release* (non-snapshot) plugin repository this is almost never desired — released artifacts are immutable, so the only effect is added network round-trips (and slower, less reliable builds) on each invocation. `interval:60` (or `daily`) already balanced freshness against performance.
   
   Suggested fix: either revert to `interval:60`/`daily`, or if `always` is intentional, update the comment to explain why frequent checks are now required. Note the `<releases>` repository block above (line 48) still uses `interval:60`, so this also introduces an inconsistency between the two repository definitions.

   Fix (Revert to interval:60 to match the comment and the releases repository above.):
   <releases>
     <enabled>true</enabled>
     <!-- no need to always check if new versions are available when executing a Maven plugin without specifying the version -->
     <updatePolicy>interval:60</updatePolicy>
     <checksumPolicy>fail</checksumPolicy>
   </releases>

2. 💡 Edge Case: artifactory vault step may emit empty output for non-deploy builds
   Files: build-maven/action.yml:146-154, build-maven/action.yml:190-192

   The new `artifactory` step requests zero secrets when `inputs.deploy == 'false'` (all three secret lines evaluate to ''), and it has no `if:` guard, so it always runs. Lines 190-192 then call `fromJSON(steps.artifactory.outputs.vault).ARTIFACTORY_DEPLOY_USERNAME` etc.
   
   Previously these deploy credentials lived in the `secrets` step, whose output was always non-empty valid JSON because it also requested `SIGN_KEY`/`PGP_PASSPHRASE`. Now, for non-deploy builds (e.g. PR builds with deploy=false), the dedicated `artifactory` step may produce an empty `vault` output. If the wrapper emits `''` rather than `{}` in that case, `fromJSON('')` would throw and fail the env evaluation of the build step for all non-deploy runs.
   
   Please confirm vault-action-wrapper outputs `{}` (not empty string) when no secrets are requested; if not, add an `if:` guard on the `artifactory` step (e.g. only when deploy != 'false') and gate the dependent env vars accordingly.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.
Unblock → Override a blocking verdict and allow merging.

Comment with these commands to change:

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

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