-
Notifications
You must be signed in to change notification settings - Fork 57
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
Sonarqube stage crashes in cnes report #663
Comments
@jssnull when you create an issue that breaks relevant behavior of our Platform, please ensure there's some traction on the topic. Especially if you are tackling this from a support perspective. Did you already include any people that can help you on that matter? |
The problem is because cnes-report (SonarQu tool) is not compatible with PR scan. cnescatlab/sonar-cnes-report#159 This is because the scan is done against the PR and not against the Branch. To solve this we have to change the Jenkinsfile in order to scan the 'Branch'. With this code: odsComponentStageScanWithSonar(context,[analyzePullRequests: false]) PS. We think that this should be the default behaviour: Not to scan PRs. Anothert option is to change all the "Quickstarters" |
I had to think a bit more about this and concluded that next to the merged solution, there is also another option. So just putting it out there as an FYI ... Instead of disabling PR scans all the time, you could disable the CNES report only when a PR scan is performed. That should work given the issue is just with the combination of PR scan and CNES report. And it would actually be an even better approach than in 3.x because you save time by avoiding to generate the CNES report for PRs. Those reports were never used anyway, as the CNES report only makes sense for main branches. |
The problem is that we need the CNES repor for the LeVA documentation, and on the other hand, the PR scan is a good feature with SQ7.9, but now we have SQ8.0+ |
AFAIK you only use the report from the |
Yes, in theory, as this is configurable |
* Do not generate reports when pull request exists for scanned branch. For more information, see opendevstack/ods-jenkins-shared-library#663 and cnescatlab/sonar-cnes-report#159. * Ensure background task on server finishes before generating a report. For more information, see opendevstack/ods-jenkins-shared-library#732. * Unify logging approach: instead of printing to STDOUT directly for some messages, funnel everything through the logger instance. Other tasks should adopt this as well. Closes #227.
* Do not generate reports when pull request exists for scanned branch. For more information, see opendevstack/ods-jenkins-shared-library#663 and cnescatlab/sonar-cnes-report#159. * Ensure background task on server finishes before generating a report. For more information, see opendevstack/ods-jenkins-shared-library#732. * Unify logging approach: instead of printing to STDOUT directly for some messages, funnel everything through the logger instance. Other tasks should adopt this as well. Closes #227.
* Do not generate reports when pull request exists for scanned branch. For more information, see opendevstack/ods-jenkins-shared-library#663 and cnescatlab/sonar-cnes-report#159. * Ensure background task on server finishes before generating a report. For more information, see opendevstack/ods-jenkins-shared-library#732. * Unify logging approach: instead of printing to STDOUT directly for some messages, funnel everything through the logger instance. Other tasks should adopt this as well. Closes #227.
* Do not generate reports when pull request exists for scanned branch. For more information, see opendevstack/ods-jenkins-shared-library#663 and cnescatlab/sonar-cnes-report#159. * Ensure background task on server finishes before generating a report. For more information, see opendevstack/ods-jenkins-shared-library#732. * Unify logging approach: instead of printing to STDOUT directly for some messages, funnel everything through the logger instance. Other tasks should adopt this as well. Closes #227.
If we've an ods quickstarter, and we create a PR for it.
If we trigger a build in the PR origin branch, the jenkins build will crash in sonarqube stage, concretely, when the cnes report
is called. It will retrieve an error like this:
After having this error, If we delete the created PR and launch a build in the same branch again, it will work.
Then, seems that the cnes report is not able to retrieve data from PR in sonarqube. This happens in sonarqube developer and above editions.
Seems that in the past, situations like this happened in cnes plugin: cnescatlab/sonar-cnes-report#159
The text was updated successfully, but these errors were encountered: