Hi there, we are trying to onboard SonarQube Cloud in our Azure DevOps tenant.
We installed the extension in ADO, and followed the steps to modify our pipeline with the sonar steps. When the build runs, the scan reports 0 files to be scanned, even if we change any of the files. Also, we are not able to figure out how to force a full scan of the repo, instead of scanning only the new code.
Follows the changes we did in our pipeline (secrets omitted):
When accessing the sonarcloud portal, we can see the new commits and there, so we guess the integration is not an issue. To configure the projects (currently 2), we followed the guide provided in the portal when creating a new project.
Can you help out please?
ALM used: Azure DevOps
CI system used: Azure DevOps
Scanner command used when applicable (private details masked)
Languages of the repository: Typescript, Nexjs
Error observed (wrap logs/code around with triple quotes ``` for proper formatting)
Using cliSources with ADO build variables (e.g. ‘$(Build.SourcesDirectory)’) doesnt work. We had to use relative paths (e.g. ‘./src’) to make it work
Non-Main branches will only scan new code, correct?
Updated files only highlight issues identified in new code, not on the existing code. Is there a setting we can use to highlight all issues identified in the modified file?
The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.
thanks for the response.
We were able to fix the problem with the code scan (invalid configuration on the cliSources).
But as per my last comment, we have a few questions pending:
Non-Main branches will only scan new code, correct?
Updated files only highlight issues identified in new code, not on the existing code. Is there a setting we can use to highlight all issues identified in the modified file?
Well… Short-lived branches only analyze new code, but you can have as many long-lived branches as you like, and they analyze all code.
Note that a branch’s … “lifespan”? (short- or long-lived) is set the first time it’s analyzed and is immutable. If the setup was wrong on that first analysis, you’ll need to delete the branch and reanalyze.
What you’re describing is a new code analysis, whether in a short-lived branch or a PR. To see all issues, make sure you’re running a full branch analysis on a long-lived branch.
thanks for the update.
In this case, we have short-lived branches (feature/bug branches) and whenever someone updates a code file with new code, we would expect the analysis to show all issues with new and existing code, so then the person can understand the issues and fix them.
Isn’t this possible?
Realistically, we have our main branch (long-lived) currently analyzed, and with issues reported. But we are not going to fix all issues now. So, organically when devs modify code, they can fix existing and new issues, as long as we have them reported on the short-lived branches.