Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate variable sonar.branch.name to sonar.pullrequest.branch #3

Closed
rverma-nikiai opened this issue Mar 29, 2019 · 10 comments
Closed
Labels
invalid This doesn't seem right

Comments

@rverma-nikiai
Copy link

Migrate variable sonar.branch.name to sonar.pullrequest.branch to be compatible with the dev edition branch plugin. sonar.branch.name is deprecated.

@nixel2007
Copy link

nixel2007 commented Mar 29, 2019

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/

@mc1arke mc1arke added the question Further information is requested label Mar 29, 2019
@rverma-nikiai
Copy link
Author

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.

@rverma-nikiai
Copy link
Author

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

@mc1arke
Copy link
Owner

mc1arke commented Mar 29, 2019

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.

@mc1arke mc1arke closed this as completed Mar 29, 2019
@mc1arke mc1arke added invalid This doesn't seem right and removed question Further information is requested labels Mar 29, 2019
@rverma-nikiai
Copy link
Author

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.

@mc1arke
Copy link
Owner

mc1arke commented Mar 30, 2019

@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.

@rverma-nikiai
Copy link
Author

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.

@mc1arke
Copy link
Owner

mc1arke commented Mar 31, 2019

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?

@4n4n4s
Copy link
Contributor

4n4n4s commented Apr 2, 2019

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?

mc1arke added a commit that referenced this issue Apr 2, 2019
A lookup is performed on the target branch of a pull request to ensure the branch exists, since SonarQube uses this as the base for collecting metrics on the Pull Request. However, the retrieved branch is then used incorrectly, with the UUID of the retrieved branch's target branch being returned as the target for the Pull Request, rather than the UUID of the retrieved branch. As long-lived branches that are generally targeted by Pull Requests will not have a target branch, this may result in a `NoSuchElementException` from SonarQube's Compute Engine when trying to use the non-existent UUID, or SonarQube showing the wrong branch as being targeted for a pull request and picking up new issues on the source branch incorrectly where a short-lived branch is targeted.

This change updates the generation of the pull request details to use the UUID of the retrieved target branch when creating Pull Request details, rather than the UUID of the target of the retrieved target branch.
@mc1arke
Copy link
Owner

mc1arke commented Apr 3, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
invalid This doesn't seem right
Projects
None yet
Development

No branches or pull requests

4 participants