Can we enable/disable these feature independently?
We want detection of new code, but we have privacy reservation about the other features. We would rather not upload this personal data to another tool/server.
We could probably anonymize the repo before running the scanner, but this seems overkill, also the commit ids would not fit any longer!
SonarQube Enterprise Edition Version 9.9.1 (build 69595)
OK, here you go. I hope this is Product Manager compatible:
We have problems with getting SQ-issues into our PRs, but those SQ-issues are in files, that we did not touch in that PR. See 101554.
The proposed solution for this is to turn on SCM, which works as expected. However, I cannot turn it on because of legal implications following.
With enabled SCM, we upload sensivitve personal data (Name, mail) to SQ. In our company we have rules that do not allow this unless other rules are followed. I am no legal expert and I do not want to become one. I just know that it is problematic to upload this data to another server or tool. You are correct, that all the information is already in git and the git hoster (Azure Devops) but I did not introduce that and therefore I am not reliable. I would be reliable if I upload it to SonarQube.
Therefore I would prefer if I could use SCM, but it did not upload names and mails. It could upload hashes, as they contain no personal information.
I think, the best way to support this to make the three already separately documented features of SCM separately configurable:
I don’t know how git and azure devops got through the process. I don’t even know which process is needed.
Our SQ Admin also does not not know, therefore he disabled SCM. We’d rather let sleeping dogs lie and not upload any personal data.
We know that we limit ourselfs by doing this, but on the other side, I am not interested in this at all. I did not even know thinks like auto assignment exist. I am only interested in a good detection of changes in a PR.
A final sad notice: At our company SQ is treated like a ugly step sister. No one wants to bother with it, no one looks at the reports. No one will look at open issues and fix them by themself. Therefore I want to enable PR annotations which will force people to look at their issues. However, I have to be careful that there are no false issues (on unchanged files), otherwise my addition will be criticized and removed instantly. I have to work with baby steps here to not anger other devs. And automatic issue assignment is not a baby step imo.
Thank you very much for the details you provided.
We take into consideration your needs. It is the first we got this feedback so for now it will not be a short-term priority. It might be in the future though.
Regarding that topic, could you elaborate? Why SQ is treated like an ugly sister? Why the value is not recognized by the developers?
Developers do not like it because we have a lot of legacy code with a lot of issues. Simple changes follow a lot of SQ changes. And fixing one SQ issue brings 2 new ones. We can not finish stories as fast as before.
This problem is increased with incomplete detection of changed lines.