We need the data because it’s a way (only?) to link a SonarQube project with a SCM project (here: GitLab) unless you use the SonarQube project key. We want to automate our CI/CD even more and set project key and project token automatically in the pipeline. Hence, remove the need for setting sonar-project.properties all together. Too much configuration of tools. SonarLint handles it nicely.
SonarLint does not use sonar-project.properties but it manages to bind nonetheless, I just haven’t been able to figure out how (I end up here and then it seems like it off to the LSP (“sonarlint/suggestBinding”). If SonarLint’s way of doing it is reliable and easy to implement then we might use that solution as well. Do you happen do have more details on this?
We will run a job in our pipeline before sonar:sonar/sonar scanner that will either create sonar-project.properties or set environment variables to be used subsequently.
I found a semi workaround. I can look for common files such as pom.xml, pyproject.toml and then use endpoint api/sources/lines to get a commit sha. I can then search for that commit sha in GitLab repo url and retrieve the project’s GitLab repo url.
UPDATE: I found some information about SonarLint’s auto suggestion here now. We did have sonar-project.properties in the git repo but removed it just to confirm. So, the question remains if the suggestions are from an API call to SonarQube or if the logic is in SonarLint.