SONARJAVA-6899 Onboard SonarJava onto the PVF

[rombirli]

Part of SONARJAVA-6899. Companion PR: SonarSource/peachee-java-kotlin#327

Onboards SonarJava onto the Performance Validation Framework, the same way SonarJS#7913 did for SonarJS.

Because this repository is public and the PVF report must stay private, the benchmark and the dashboard are hosted in peachee-java-kotlin (as SonarJS hosts its in peachee-js). This PR only adds the two ends of the handshake:

• build.yml records the deployed plugin version as the candidate-version artifact.
• pvf-comment.yml turns a /pvf comment on a PR into a workflow_dispatch of performance-validation-java.yml in peachee-java-kotlin, which benchmarks that version and comments the dashboard link back here.

Usage once merged

Comment /pvf on a PR to benchmark every rule, or /pvf S1234, S5678 to restrict the run to specific rules.

Prerequisites, all landed

• Vault token pvf-dispatch for this repository, with actions:write on peachee-java-kotlin — re-terraform-aws-vault#9750
• The host-side tokens and the GitHub Pages build_type switch, both listed on the companion PR

Testing

The build.yml half is proven by this PR's own Build run: it published candidate-version = 8.45.0.59032.

The host side is proven too. 8.45.0.59032 was benchmarked against a baseline pinned two releases back, over the full 140-project matrix, in peachee-java-kotlin run 37020618474: every project built and prepared, the issue diff reported real rule differences, and the dashboard published to GitHub Pages. That exercises the project matrix, the build delegation, the server context, the report publication and the issue diffing. See peachee-java-kotlin#329 for how that run was triggered.

What remains untestable before merge is only the first hop: GitHub registers an issue_comment workflow and a workflow_dispatch target only once the file sits on the default branch, so /pvf cannot fire from a branch on either side. That hop is the shared pvf-trigger action already in production for SonarJS, so it is not new code.

Merge order

The companion PR has to merge first, because pvf-comment.yml dispatches performance-validation-java.yml against peachee-java-kotlin's master. After both are in, comment /pvf here to confirm the last hop end to end.

[hashicorp-vault-sonar-prod]

SONARJAVA-6899

[rombirli]

Gitar, Valid but conditional on SonarSource/core-languages-tooling-public#70, still open. SonarJS has same permission, keeping parity.

[rombirli]

Tested here https://github.com/SonarSource/peachee-java-kotlin/actions/runs/37020618474

[alex-meseldzija-sonarsource]

LGTM, just change the pull-request to write so we dont have to do it later.

[gitar-bot]

Code Review ✅ Approved 1 closed / 1 findings

🟡 Medium risk · The /pvf comment workflow dispatches a cross-repository performance run, so matching comments could trigger unintended benchmark runs.

Onboards SonarJava onto the Performance Validation Framework by adding workflow automation to publish the built plugin version and dispatch performance benchmarks via /pvf comments, resolving the pull-requests read permission issue that was blocking the pvf-trigger feedback.

✅ 1 closed

✅ Cross-PR: pull-requests: read blocks pvf-trigger feedback added by tooling PR #70

📄 .github/workflows/pvf-comment.yml:16-20 📄 .github/workflows/pvf-comment.yml:44
This depends on another open PR. This workflow (sonar-java#6288, head bd3d709) calls SonarSource/core-languages-tooling-public/pvf-trigger@master, which is a moving ref, and only grants pull-requests: read. core-languages-tooling-public#70 (head 0e5b127c9ce9b85386289b99f79331aefe9a5e92) changes that action in two ways. It adds a 👀 reaction, which is best-effort. It also adds an if: failure() step that runs gh pr comment to tell the commenter why the dispatch failed. That step is not best-effort, and the PR says callers must raise pull-requests to write to get the feedback. Condition: once #70 is merged to master, any failed /pvf dispatch here (for example, Build has not uploaded candidate-version yet) will have its failure-report step fail with a 403 from gh pr comment. The commenter gets no feedback, the run shows an extra failed step, and the 👀 acknowledgement on successful runs is silently skipped.

Review coverage

🧪 Functional validation No results

📋 Rules No rules evaluated

📖 Knowledge used 1 confirmed expected behavior

Cross-repo coverage 1 repository selected

🤖 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}

[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