We have an Open Source project, Egeria GitHub - odpi/egeria: Open Metadata and Governance
Our ‘regular’ build pipeline is now via Github actions - we build with both maven and gradle (migrating to)
We do various builds triggered off a PR, and a few more (like updating snapshots) from merge
We still have a few ‘old’ pipelines on Azure DevOps, including a sonar build for sonarcloud (maven). This also captures code coverage from tests. It’s triggered off a merge
In the last year we’ve tried out GitHub’s ‘codeQL’ and integrated into our github actions/PR pipeline. This is nice as the dev gets results in-situ. However reviewing the backlog is unusable (just a list in github) and the detection of errors is not very good.
I’m wondering if we can get SonarCloud working in the same way? ie to insert PR-specific results
into the checks output / PR review.
I see automatic analysis isn’t supported for java, so this needs to be CI driven?
Ideally github action, but could be Azure devops too if we had to…!
you need to provide the token for forks, hence that you can not store it in a secret.
if somebody in a fork opens a pr within this fork, you might get a comment on the main repository with an pull request with the same ID (quiet annoying, thats why we turned off this information)
you can also wait for the quality gate to fail when you run a github action, so you get some kind of breaking build.
It is possible (and highly encouraged!) to analyze pull requests with SonarCloud. We provide high-level feedback directly inside the PR as well. You can find more information around the GitHub integration here.
Yes, in your case it will be CI driven, and it is very easy to set it up with Maven or Gradle.
As @simon.schrottner mentioned, analysis of external pull requests (e.g. from forks) is currently a bit difficult. You can follow this item on our roadmap for updates regarding this feature.
Thanks. It is indeed this scenario that is causing us difficulty so glad to see it is on the roadmap.
Even though I’m a maintainer on our project, almost ALL code changes go via the ‘external PR’ process (exceptions being admin like creating a branch etc, that is all). We hit that same issue with secrets and not quite figured out the best way of handling it. Instead we are now trying other scanners (sonatype lift and codeQL) though I think sonar has a lot to offer.
Ultimately though the best way of encouraging the code to be corrected is to ensure the developer and reviewer sees as early as possible. IDE integration is fine, but requires the developer to do something … PR integration is a good balance and we’re already seeing those other scanners, whilst not as good IMO (though all have pros/cons) causing developers to ACT & improve their code.
