-
-
Notifications
You must be signed in to change notification settings - Fork 509
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
Projects created automatically are broken #738
Comments
I don't think this can work the way you want. Sonarqube needs to have the analysis of the target branch in place before it can perform a Pull Request analysis, so dynamically creating a project during pull request submission isn't something that would feasibly allow this since the target branch couldn't already exist in Sonarqube and Sonarqube would therefore find no baseline to work against. The error messages could probably do with some clarification here, but I'm closing this as invalid given Sonarqube core can't support this way of working |
Well, shouldn't at least the scan fail more gracefully in this case? For example, instead of having the project created brokenly in Sonarqube, requiring some administrator to delete the broken project and recreate it manually, it could simply fail during the first scan saying "please create the project in Sonarqube before issuing the first scan". |
Thanks for the answer by the way. |
I don't think this is the case, not according to my tests. As long as the branch is also fetched by git during the pull request analysis, the Sonarqube analyses it just fine. I did a few tests for it (without having Sonarqube scanned the branch prior to the PR analysis).
But this is exactly what happens today: the project gets created automatically but without the branch, and I'm reporting that, as part of the automatic creation of the project, I'd say the branch had to be created as well. |
Hi, I upgraded today from 8.9 LTS with plugin 1.8.1 to LTS with plugin 1.14.0. Now I can not do anything. Not even manually go to sonarqube.xxx.com/project/branches?id=Project_Name to see what I have and what I am missing. I am running branch to which the PRs were merging now (our main development branch) and will report if that fixed the problem. |
So the moment that analysis was scheduled (it is still in progress) everything is back OK. |
I have looked into this problem. For the following explanation, we will run an analysis for a non-existant branch with directly a merge request. My analysis is the following :
The brutal solution would be to destroy the project, then re-create it properly. The clean solution is to remove only the errors. Database You can run a small query to get the project key. It will be needed for the API API Once you have done that, your project is now available. If you are interested, I have developed a small Python script to perform that :) |
Hi, I got it back up and running by manually performing analysis of the target branch (my main branch). |
Anyway, it's not necessary to perform an analysis of the target branch. The only requirement is that the target branch exists in SonarQube (it does not need to be analyzed). This is why I think a pull request execution should also create the target branch automatically. |
You can't have a branch in Sonarqube without an analysis, and having a branch without an up-to-date analysis would render the PR analysis as invalid since the baseline wouldn't have all the findings to perform a comparison against
This isn't something that would be reasonable to try and support since it would give potentially misleading results. The scanner component that submits details for analysis also does not support submitting more than the currently checked-out branch, so this operation wouldn't be feasible. |
According to my tests you are wrong in this statement. However, let's assume you are right. So, someone is trying to add the sonarqube scan to their project. The way how the scan is introduced in the CI workflow has to be through a PR, then, after PR is merged, Sonarqube is finally able to scan the branch for the first time and produce meaningful results for the following PR scans. However, with the current behavior, the user would be stopped to even merge the PR to begin with. What's your proposal to that? In my opinion, even if you were right about the scan producing misleading results, it should be acceptable as a first time scan (otherwise the person can't even merge the PR which adds the scan and thus the scan will never run for the branch).
But I'm not talking about publishing an analysis of the branch while in pull request mode. I'm talking about creating the branch for the project (without publishing any analysis for the branch), that's a different thing. |
Does your branch has special charachters? If there is could you try to put your branch name in single quotes? |
Mine hasn't (branch name is "develop"). |
Doing this means that I now get no results in the SQL query but the project is still unavailable |
Honestly, I have tested this procedure in SonarQube 9.8. |
In my case, it's SonarQube 9.9.1 LTS. |
9.9.1.69595 for me. Any idea what else I can try to look into? |
@Wihrt apologies that did work for me. I have no idea why the SQL request didn't return the problem after the first time I tried. Maybe I misread or changed the command somehow. Anyway, I did find one problem which was that you have to |
@mc1arke I think there is a bug here. If you create a pull request from one branch to another that is not scanned, it completely crashes the whole project in Sonarqube. In my case I created a new branch from a colleagues' slightly longer-running branch and it broke everyone's use of Sonar. I'm happy for my PR to not work but it shouldn't break the whole project |
The scanner currently skips validation of a target branch if a Pull Request is used to create a new project, so the resulting project fails to load in front-end due to the Pull Request API treating the data on that pull request as invalid. This is being overcome by validating that a target branch exists for all Pull Request submissions and rejecting the scan submission if the target branch is not found in Sonarqube. Additionally, there's a delay between a Pull Request being recorded in the database by the server component as a result of the call from the scanner, and the Compute Engine recording the Pull Request details (source, target, title etc.) against the branch. During this time the Pull Request treats that Pull Request as invalid and throws an error, meaning the project cannot be loaded through the UI, or the Pull Requests listed through the API. As the Pull Request response fields filled from the Pull Request data are not mandatory, those fields are now only being completed if the Pull Request data is set on the branch DTO rather than throwing an exception if the data isn't set.
The scanner currently skips validation of a target branch if a Pull Request is used to create a new project, so the resulting project fails to load in front-end due to the Pull Request API treating the data on that pull request as invalid. This is being overcome by validating that a target branch exists for all Pull Request submissions and rejecting the scan submission if the target branch is not found in Sonarqube. Additionally, there's a delay between a Pull Request being recorded in the database by the server component as a result of the call from the scanner, and the Compute Engine recording the Pull Request details (source, target, title etc.) against the branch. During this time the Pull Request treats that Pull Request as invalid and throws an error, meaning the project cannot be loaded through the UI, or the Pull Requests listed through the API. As the Pull Request response fields filled from the Pull Request data are not mandatory, those fields are now only being completed if the Pull Request data is set on the branch DTO rather than throwing an exception if the data isn't set.
Would it be possible to get this change for v1.14, to provide this for Sonarqube 9.9 LTS? I'm not opposed to making the PR, assuming it's just the same code as the fix in v1.17, but this would be my first contribution so wanted to ask first. |
That would be super nice for me as well. |
More details in: https://github.com/mc1arke/sonarqube-community-branch-plugin/pull/847/files - Bumping the version to 1.14.1
@mc1arke is it very hard to release a newer version of the plugin for SonarQube 9.9 LTS? |
Describe the bug
If I run
mvn sonar:sonar
with thesonar.pullrequest
parameters for a project that does not already exist in Sonarqube, the project gets created automatically.However, in that case, the project that gets created in Sonarqube is apparently broken because when I try to open it from the UI this shows up:
Digging a bit further, this issue is apparently related to the branch name of the project. I think the project does not get created by the plugin with the correct branch name set as the main branch.
If I create the project manually first in SonarQube, and set its main branch to the correct branch, then
mvn sonar:sonar
works as expected.To Reproduce
mvn sonar:sonar
with thesonar.pullrequest
parameters for a project that does not exist already in Sonarqube.Expected behavior
To have the project created with the target branch
sonar.pullrequest.base
set as the default branch.Screenshots
See above.
Software Versions
Additional context
This causes the Sonar Gerrit Jenkins plugin to fail for some weird reasons like:
SonarQube analysis 'AYaAYSId_x56GYGzmtJ8' failed with message: Could not find target branch 'null' in project.
The Sonarqube logs shows things like:
The text was updated successfully, but these errors were encountered: