[
https://issues.apache.org/jira/browse/CAMEL-23274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18071849#comment-18071849
]
Guillaume Nodet edited comment on CAMEL-23274 at 4/8/26 5:11 AM:
-----------------------------------------------------------------
I've been working on this and have a working approach using the workflow_run
two-stage pattern, which addresses most of the concerns raised:
How it works:
- sonar-build.yml triggers on pull_request — builds the project, runs tests
with JaCoCo coverage, and uploads compiled classes + PR metadata as artifacts.
No secrets needed here, so forks work fine (addresses point 1).
- sonar-scan.yml triggers on workflow_run completion of SonarBuild —
downloads the artifacts and runs the Sonar analysis using SONARCLOUD_TOKEN from
the base repo. This is the GitHub-recommended pattern for fork PRs with secrets.
What's been merged:
- PR #22446 / #22468: The two-stage workflow with coverage on core modules
Addressing resource concerns (points 2 & 3):
- I'm working on incremental module detection (PR #22247 + #22469) so that
only modules modified in the PR get built/tested/scanned, not the full 300+
modules. This keeps build time reasonable.
- SonarCloud PR analysis already reports only on "New Code" metrics, so we
don't need full project coverage.
Current status:
- Temporarily disabled (PR #22477) because the default SonarCloud quality
gate is too strict for an existing large project (0% coverage → instant
failure). Filed INFRA-27808 to get the quality gate adjusted.
- Also filed fixes for security hotspots (#22480), critical bugs (#22478),
and CPD exclusions (#22479).
Plan forward:
1. Get quality gate adjusted (INFRA-27808)
2. Merge incremental build detection (#22247)
3. Re-enable with scoped analysis on modified modules only
This avoids the local Sonar server approach entirely — no Docker overhead, no
8-hour builds, and we get native PR decoration from SonarCloud.
was (Author: gnt):
I've been working on this and have a working approach using the workflow_run
two-stage pattern,
which addresses most of the concerns raised:
How it works:
- sonar-build.yml triggers on pull_request — builds the project, runs tests
with JaCoCo
coverage, and uploads compiled classes + PR metadata as artifacts. No secrets
needed here, so
forks work fine (addresses point 1).
- sonar-scan.yml triggers on workflow_run completion of SonarBuild —
downloads the artifacts and
runs the Sonar analysis using SONARCLOUD_TOKEN from the base repo. This is
the
GitHub-recommended pattern for fork PRs with secrets.
What's been merged:
- PR #22446 / #22468: The two-stage workflow with coverage on core modules
Addressing resource concerns (points 2 & 3):
- I'm working on incremental module detection (PR #22247 + #22469) so that
only modules
modified in the PR get built/tested/scanned, not the full 300+ modules. This
keeps build time
reasonable.
- SonarCloud PR analysis already reports only on "New Code" metrics, so we
don't need full
project coverage.
Current status:
- Temporarily disabled (PR #22477) because the default SonarCloud quality
gate is too strict for
an existing large project (0% coverage → instant failure). Filed INFRA-27808
to get the quality
gate adjusted.
- Also filed fixes for security hotspots (#22480), critical bugs (#22478),
and CPD exclusions
(#22479).
Plan forward:
1. Get quality gate adjusted (INFRA-27808)
2. Merge incremental build detection (#22247)
3. Re-enable with scoped analysis on modified modules only
This avoids the local Sonar server approach entirely — no Docker overhead, no
8-hour builds, and
we get native PR decoration from SonarCloud.
> [build] Provide a static code analysis for each PR
> --------------------------------------------------
>
> Key: CAMEL-23274
> URL: https://issues.apache.org/jira/browse/CAMEL-23274
> Project: Camel
> Issue Type: Improvement
> Reporter: Pasquale Congiusti
> Priority: Minor
>
> I've done several experiments in the past, so, let me include here my
> evaluations in order to be all on the same page and avoid running in circle.
> Having a full static code analysis on the entire project for every PR using
> the Sonarcloud server is not going to work for several reasons:
> 1) Token is likely not to be available on PR from forks for security reasons
> 2) Limited resource on the sonarcloud server to run many analysis (we have
> days with 10/20 PRs)
> 3) Impossibility to run the entire coverage as an entire execution takes 4
> hours.
> 4) Difficulty to call the sonar API and get results to return on the PR with
> the diff between the scan analysis and the base one.
> A possible solution I've tried in the past was to have a sonar server running
> locally (via docker container). This could be a solution as it does not
> involve any secret management and it would be entirely ephemeral. The idea is
> to launch a docker server locally, build and scan the target branch (ie,
> main) and store the base result. Then, build and scan the PR code. Finally,
> once completed, we can get the result and the diff calling the API of the
> local sonar and returning the main metrics with a PR comment.
> The biggest difficulty of this approach is the impossibility to run both
> entire tests in order to get the coverage as, the overall could take up to
> 8/10 hours (which makes this not viable). Beside the coverage, the rest of
> metrics would be still available, but, we need to understand if it makes
> sense, as each PR time could be increased by 1 or 2 hours.
> In January 2026 we have introduced a monthly communication to the dev mailing
> list in order to share the evolution of the static code analysis for the
> difficulty of having a full automatic workflow, and, the same github has a
> notification mechanism to read and provide warning for major security issues,
> checking data on the same sonar cloud.
> We therefore need to understand the priority of this activity, which, IMO, is
> low, given that we have already a process (altought it's manual).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
