Closed rverma-nikiai closed 5 years ago
Could you provide link to the deprecation issue? I know about deprecation of sonar.branch
, but all docs says that we should use sonar.branch.name
7.7 docs https://docs.sonarqube.org/latest/branches/overview/
My bad, it was sonar.branch which got decommissioned. I was referring to https://docs.sonarqube.org/latest/analysis/pull-request/ and I believe I had seen in the developer edition trial a corresponding suggestion.
I believe as per docs
sonar.pullrequest.branch | The name of your PREx: sonar.pullrequest.branch=feature/my-new-feature |
---|---|
sonar.pullrequest.key | Unique identifier of your PR. Must correspond to the key of the PR in GitHub or TFS. E.G.: sonar.pullrequest.key=5 |
sonar.pullrequest.base | The long-lived branch into which the PR will be merged. Default: master E.G.: sonar.pullrequest.base=master |
do serves the same functionality.
Also, I am willing to work on GitHub pull request decoration since the plugin https://github.com/SonarSource/sonar-github is now deprecated. Do you want to include this in the same repo to make it at par with developer edition pull request analysis
Yes, I'm happy to have this in the same project. I'll try and publish an example branch of how I'd like this to work during the next week, but feel free to raise a PR before then.
https://github.com/nikiai/redmine-import/pull/1/files , this was the trial which I did with developer edition which was reflecting complete analysis. As you see no sonar.branch.x was required. It was reflecting correctly in the console. One can try the same behavior with sonarcloud as well.
@rverma-nikiai You'll need to provide more detail around the inputs you're providing, what your expected results are, and what your actual results are, as I can't tell from the link you're provided.
sonar.projectKey=nikiai_redmine-import
sonar.organization=nikiai
sonar.host.url=https://sonarcloud.io
sonar.pullrequest.branch=feature/tst-12
sonar.pullrequest.key=1
sonar.pullrequest.github.repository=nikiai/redmine-import
sonar.java.binaries=build/classes
The point is that above was the only specified input for pr analysis required with sonarcloud(which includes developer edition's pr analysis plugin).
Anyways apart from that I am struggling with kickstarting the github pull request reporting part. In absence of preview mode, I was hoping to get this using PostProjectAnalysisTask but I am unable to retrieve the issues. Any hints would be appreciated.
Does the official SonarQube branch plugin provide details on individual issues, or just the metrics in the Quality Gate? From the documentation and having checked a couple of repositories on Github, it looks like SonarCloud is setting the project's Quality Status based on the Quality Gate rather than parsing individual issues.
If it is just the QualityGates being used then implementing PostProjectAnalysisTask
and iterating through projectAnlysis.getQualityGate().getConditions()
should provide you each measure, the current state, the current value, and the expected value.
If individual issues are being used to provide in-line commenting like the old Github plugin used to do then I'll need to do a bit of further analysis of the SonarQube code base, as there are other analysis extension points we may be able to use, but I'm not sure how well they may suit the requirements.
Do you have any example links or screenshots of a pull request that's been decorated by SonarQube that has introduced new issues/failures so I can see what decoration SonarQube has performed?
PostProjectAnalysisTask would be an option. However what I don't know is as you also wrote what details do you get here.
Another plugin that we were using previously used a PostJob to add the comments to a pullrequest (bitbucket server). They decorated it manually using comments and an overview comment. https://github.com/AmadeusITGroup/sonar-stash/blob/master/src/main/java/org/sonar/plugins/stash/StashIssueReportingPostJob.java
Would be cool to see, as you also mentioned, what the standard SonarQube pull request decoration looks like and if we can (re)use it.
As far as I can see bitbucket server support starts in SQ 7.7 https://docs.sonarqube.org/latest/analysis/pull-request/ Previous versions of 7.x don't have support for example for "sonar.pullrequest.bitbucketserver.serverUrl".
What do you think about bumping the plugin to SQ 7.7? What are the general improvements that you want to make?
I don't believe we need to bump to SQ 7.7 as we shouldn't be dependent on anything new in SQ core to make use of sonar.pullrequest.bitbucketserver.serverUrl - it would just be a property the plugin would define and make use of. However if there does turn out to be a feature dependency then I'm happy to update at the point we uncover that.
From having looked at a couple of Github projects that seem to have SonarQube/SonarCloud reporting to them, it looks like updates are being made to the 'Checks' status on a Pull Request to show the Quality Gate state, but not the addition of any inline comments to show underlying issues. If additional things are happening, or this works differently with Bitbucket or VSTS/Azure Devops then I need someone who uses those tools to confirm what happens.
Migrate variable sonar.branch.name to sonar.pullrequest.branch to be compatible with the dev edition branch plugin. sonar.branch.name is deprecated.