On Mon, 6 Jan 2025 at 16:47, Konrad Windszus <k...@apache.org> wrote: > > Leveraging Automatic Analysis cannot calculate code coverage. Therefore the > option with two different GHAs should be used (as outlined in > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=321719166#GitHubActionsSecurity-Buildstriggeredwithworkflow_run).
We should not use workflow_run in such a case ... we still want to execute untrusted code with github write permission. It is not a good idea. > Regards, > Konrad > > > On 5. Jan 2025, at 12:59, Gerd Aschemann <g...@aschemann.net> wrote: > > > > The link is more than three years old. One of the replies from SonarQube > > contains a link that states that it is meanwhile (Aug 24) possible for > > projects configured for Automatic Analysis > > (https://portal.productboard.com/sonarsource/1-sonarqube-cloud/c/50-sonarcloud-analyzes-external-pull-request). > > > >> On 5. Jan 2025, at 10:21, Slawomir Jaranowski <s.jaranow...@gmail.com> > >> wrote: > >> > >> https://community.sonarsource.com/t/code-analysis-on-pull-request-from-forked-repository-with-github-actions/43986 > >> > >> On Sun, 5 Jan 2025 at 02:58, Gerd Aschemann <g...@aschemann.net> wrote: > >>> > >>> > >>> > >>>> On 4. Jan 2025, at 22:28, Slawomir Jaranowski <s.jaranow...@gmail.com> > >>>> wrote: > >>>> > >>>> On Thu, 2 Jan 2025 at 14:10, Konrad Windszus <k...@apache.org> wrote: > >>>>> > >>>>> Hi, > >>>>> Maven currently does not leverage SonarQube analysis (nor any other > >>>>> static code analysis). Although onboarding currently requires one INFRA > >>>>> ticket per repo > >>>>> (https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=SonarCloud+for+ASF+projects) > >>>>> this is a one time action and the benefits from my PoV outweigh the > >>>>> efforts. > >>>>> > >>>>> The UI exposes important metrics (look e.g. at > >>>>> https://sonarcloud.io/summary/new_code?id=apache_jackrabbit-filevault-package-maven-plugin&branch=master) > >>>>> and there is also integration in GitHub PRs > >>>>> (https://docs.sonarsource.com/sonarqube-cloud/improving/pull-request-analysis/) > >>>>> and IDEs > >>>>> (https://docs.sonarsource.com/sonarqube-cloud/improving/sonarlint/). In > >>>>> addition one can configure quality gates with regards to code coverage > >>>>> or issues > >>>>> (https://docs.sonarsource.com/sonarqube-cloud/improving/quality-gates/). > >>>>> > >>>>> Leveraging this would improve the code quality and gives some pointers > >>>>> on PR quality. > >>>>> WDYT about enabling this for https://github.com/apache/maven? > >>>> > >>>> I use sonar in my work and I like it .... but for analizes we need to > >>>> provide a token ... it will not be possible in a simple way for PR > >>>> from forked repo. > >>>> So we have analize on master branches ... and it will be too late > >>>> I am afraid that we have next reports like we have for checkstyle, pmd > >>>> which will not be maintained … > >>> > >>> Granting the “Execute Analysis” permissions to anyone should enable > >>> checks from local machines, as well as from PRs (GitHub actions). > >>> > >>> That being said, I was recently told by SonarCloud support staff that > >>> granting this permission to anyone is a bad idea: > >>> https://community.sonarsource.com/t/401-during-gh-workflow-of-gradle-sonar-task-with-sonarcloud/132159/7?u=ascheman > >>> - And that they even drop that in the future. > >>> It is not yet clear to me, why they consider this _a very bad idea_? > >>> Perhaps since one could also upload analysis results to the project? I > >>> have asked back what is the background: > >>> https://community.sonarsource.com/t/401-during-gh-workflow-of-gradle-sonar-task-with-sonarcloud/132159/12 > >>> > >>> I still think that it is nice to check for the quality gate, even > >>> anonymously. Probably it should not be possible to publish results to the > >>> server. Then they should split the permission: Enable analysis for > >>> anyone, but prohibit uploading of results unless particular upload > >>> permissions are set for the user represented by a token. > >>> > >>> -- > >>> Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) > >>> +49/173/3264070 -- g...@aschemann.net -- http://www.aschemann.net > >>> > >> > >> > >> -- > >> Sławomir Jaranowski > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > > > > -- > > Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) > > +49/173/3264070 -- g...@aschemann.net -- http://www.aschemann.net > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Sławomir Jaranowski --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
