Not sure about Elliotes NPEs. The ones I checked were valid, e.g.: https://sonarcloud.io/project/issues?open=AZQn8ht1KAwsFelognsS&id=support-and-care_maven
And even when calling another method inbetween, the explanation is excellent: https://sonarcloud.io/project/issues?issueStatuses=OPEN%2CCONFIRMED&types=BUG&id=support-and-care_maven&open=AZQn8f7JKAwsFelogmUV I agree that a private constructor in a (final) utility class is a design choice, but it is very reasonable and will prevent you from doing stupid things with the class (or breaking it). Then, all the missing interrupts seem very reasonable. There are also unclosed resources (which should go into a try-w-r), all valid that I saw. And this one seems like a false positive with Optional: https://sonarcloud.io/project/issues?issueStatuses=OPEN%2CCONFIRMED&types=BUG&id=support-and-care_maven&open=AZQn8g4DKAwsFelogm9l But all in all, it looks okayish to me and reasonable for PRs. This way we could identify new(!) problems before adding them in. Cleaning up is a different beast. My +1 for diffs on PRs. - Ben Am So., 5. Jan. 2025 um 13:01 Uhr schrieb Gerd Aschemann <g...@aschemann.net>: > > 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
