[
https://issues.apache.org/jira/browse/CAMEL-23274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18071888#comment-18071888
]
Pasquale Congiusti commented on CAMEL-23274:
--------------------------------------------
Thanks for adding the info.
The problem I see with this approach is that it is not linear and the compiled
classes of a given source code are later associated to some other source code
although, if nobody tampers it, it should be the same. Not sure it is a best
practice and if it can introduce some potential security issue. Also, looking
at
https://github.com/apache/camel/blob/d203a343082809d13ac495e69137951b94d61a8d/.github/workflows/sonar-scan.yml#L91
I guess there could be situations where this artificial merge will fail
because of conflicts, given that it is not done via a regular pull request
mechanism.
> [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)
