CAMEL-22752: Add SonarCloud PR analysis workflows

[gnodet]

Summary

Add two-workflow pattern for secure SonarCloud analysis on pull requests (including PRs from forks):

• sonar-build.yml: triggered on pull_request, builds the project with mvn install -Dquickly and uploads compiled classes + PR metadata as artifacts. No secrets needed.
• sonar-scan.yml: triggered on workflow_run completion of SonarBuild, downloads artifacts and runs sonar:sonar in the main repo context with access to SONAR_TOKEN secret.

This follows the same pattern used by Apache Ignite (IGNITE-20466) and Apache Kvrocks for safe SonarCloud analysis on fork PRs.

How it works

1. PR is opened → SonarBuild runs (no secrets, just compiles and uploads artifacts)
2. SonarBuild completes → Sonar Quality Pull Request Analysis triggers via workflow_run (has access to SONAR_TOKEN)
3. SonarCloud decorates the PR with quality gate results and inline comments

Design decision: separate build vs merging into existing PR build

The SonarBuild workflow is kept separate from the existing Build and test workflow (pr-build-main.yml). The trade-off:

	Separate (current)	Merged into existing
CI cost	~12 min extra compile per PR	No extra cost
Coupling	Independent — sonar runs even if tests fail	Tied to test pipeline
Complexity	Simple, self-contained	Need to add artifact upload to one matrix job only (JDK 21)
Build approach	mvn install -Dquickly (lightweight)	regen.sh (full regen, git clean -fdx)

Merging is possible later if CI cost is a concern. Open to feedback on this.

Prerequisites

• SONAR_TOKEN secret: already configured ✅
• SonarCloud project apache_camel under the apache organization: already exists ✅

Tested on

Validated end-to-end on gnodet/camel#10 — SonarCloud successfully posted quality gate results on the PR.

Test plan

• Tested on fork (gnodet/camel) with full build + scan chain
• Verified SONAR_TOKEN is available in apache/camel secrets
• Verify the workflow_run chain triggers correctly on apache/camel after merge

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using build-all, build-dependents, skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[squakez]

A few considerations:

1. the sonar scan is not running, so cannot evaluate how long this is taking to complete a code analysis and what kind of data we have there.
2. How do we evaluate the success metric of an analysis? we miss to get back the result of the execution and, above all, a comparison with a scan on the branch where we're asking to merge.
3. AFAIK the sonar token is not going to be available for the PR for security reason, not sure the trick to bypass it via a task succession is really going to work.
4. Number of execution the sonar server can handle: I doubt we can handle tens of execution per day on the server (we have many PRs pushed daily, above all lately...). The operation is costly and we may be capped on the sonar server for sure.

[squakez]

CAMEL-22752 was closed, so, I don't understand the insistence of picking up closed issues and working on tasks that have clearly marked as no longer needed. In order to provide more context, I've created a new issue CAMEL-23274 where I explain which could be the potential alternative viable approaches: there are important constraints to evaluate though. However, the priority is lower and we have much more important tasks to dedicate our effort IMO.