Languages: The code is written in C#. It’s a Unity project.
We are analysing the PRs after they’re merged using a Github action. We aren’t using the sonarcloud-github-action, but aur script calling SonarScanner for .Net.
All was working fine until we updated from Java11 to Java17 and from SonarScanner for .Net from 5.11 to 5.14.
Java17 was mandatory, and we updated to SonarScanner for .Net 5.14 to get rid of the sonar.login warnings.
Since we updated the project in SonarCloud has a fes lines of code instead of thousands.
We’re checking the SonarScanner logs and we don’t see anything suspicious.
We’ve been making changes with some parameters but we aren’t able to get it working again.
Something that caught of guard here was the download of a cache (used for Pull Request Analysis) when in fact, what gets submitted to SonarCloud is a branch analysis.
2023-12-14T15:25:38.9276088Z 15:25:38.927 Incremental PR analysis: Automatically detected base branch 'develop' from CI Provider 'GitHub Actions'.
....
2023-12-14T15:25:39.8004267Z 15:25:39.8 Downloading cache. Project key: sonar_project, branch: develop.
2023-12-14T15:25:39.8017671Z 15:25:39.801 Incremental PR Analysis: Requesting 'prepare_read' from https://ea6ne4j2sb.execute-api.eu-central-1.amazonaws.com/current/v1/sensor_cache/prepare_read?organization=sonar_org&project=sonar_project&branch=develop
2023-12-14T15:25:40.9621484Z 15:25:40.961 Incremental PR analysis: 3472 files out of 3473 are unchanged.
....
2023-12-14T15:27:54.2797766Z 15:27:50.873 INFO: ANALYSIS SUCCESSFUL, you can find the results at: https://sonarcloud.io/dashboard?id=sonar_project&branch=develop
As it would turn out, you’re explicitly passing sonar.branch.name in your pipeline
Are you trying to force this to be a branch analysis even when it’s being triggered by a Pull Request (GITHUB_BASE_REF is only set in the context of a PR, if I’m not mistaken)?
This shouldn’t be the result (we should probably check if sonar.branch.name is set and forgo the cache if that’s the case), but I want to check what your intention is.
Yes this is a Github Action that’s triggered when a PR is merged.
I just want to analysis the base branch where the PR is merged but for the Github Action is still a PR.
I copy a few lines from the action for you to understand what are we doing:
The scanner was working fine with version 5.11. I updated it first to 5.14 to avoid the warning about use sonar.login instead of sonar.token. I updated again to 5.15 and it continues happening.
Basically what’s happening is that the scanner thinks (rightfully so) that it’s running in the context of a pull request, and therefore is configured to use a cache that prevents most of the code from being analyzed again (during the .NET bulid, where the Roslyn analyzers run)
But because you’ve set sonar.branch.name, the scanner assumes it has information for all files.
This is an unexpected state that we should probably solve by doing something like detecting that sonar.branch.name has been set and then not using the cache if so.
That said, we don’t expect most users to force a branch analysis in the context of a pull request.
For now, you could downgrade to the older scanner version before we introduced the cache abilities (and live with the warning), or set up a separate build for your branch analysis and let PR analysis function as it is supposed to.
Somebody from the team will be along to look at this thread and make a decision about what to do for future versions soon.
I’ve tried to modify the Github action to be executed outside the PR.
The github action trigger is:
name: SonarScan After Merge
on:
workflow_dispatch:
push:
branches:
- branch_name
But the results are the same, I continue seeing in the logs:
Mon, 08 Jan 2024 16:05:02 GMT
16:05:01.062 DEBUG: Incremental PR analysis: Adding hash for 'Assets/...er.cs' to the cache.
Mon, 08 Jan 2024 16:05:02 GMT
16:05:01.064 DEBUG: Incremental PR analysis: Adding hash for 'Assets/...e.cs' to the cache.
Mon, 08 Jan 2024 16:05:02 GMT
16:05:01.065 DEBUG: Incremental PR analysis: Adding hash for 'Assets/...ge.cs' to the cache.
Mon, 08 Jan 2024 16:05:02 GMT
16:05:01.065 DEBUG: Incremental PR analysis: Adding hash for 'Assets/....cs' to the cache.
Mon, 08 Jan 2024 16:05:02 GMT
16:05:01.065 DEBUG: Incremental PR analysis: Adding hash for 'Assets/...M.cs' to the cache.
Mon, 08 Jan 2024 16:05:02 GMT
16:05:01.065 DEBUG: Incremental PR analysis: Adding hash for 'Assets/...r.cs' to the cache.
Is there any way to call SonarScan inside the Github Action and get the Branch Analysis as expected?
After some investigation we found out that the branch analysis is working when we use the sonar triggered on push with the long-lived branches, but not with the short-lived as the changes can be wrong because in the push trigger we can’t really now the target branch as we did when we were using the pull_request trigger.
I don’t really understand how do you expect it to work, but you’re complicating the usage of the scanner when it can decide what to do instead of follow the instructions from the parameters.
Thanks for raising this.
I would first like to say that the documentation is a bit misleading.
I will raise this to our documentation team to mention something like this for a GitHub action:
Based on the aforementioned, the expected use-case of the scanner is as follows:
User creates a PR (github: workflow pull_request, type opened)
Analysis is run on the PR. GitHub sets three properties as environment variables, so we can detect automatically that this is a Pull Request analysis context and you get out-of-the-box a faster scan.
You make changes on your PR (github: workflow pull_request, type synchronize)
Same as before, pull request analysis works automatically.
User merges PR to whatever-42. (github: workflow push, branch whatever-*)
Analysis is run on the branch. Here, you get the default full analysis, which is slightly slower.
Again, the detection of using the Pull Request cache or not is happening with the environment variables that github sets automatically. A user can override these, but usually it should not be needed.
Furthermore, I would like to draw your attention to this part of your scanner step:
/d:sonar.branch.name=${GITHUB_BASE_REF}
Imagine you have a PR: whatever-42 → master.
Here, you are setting sonar.branch.name (expected to be set by github to the current branch == whatever-42)
to GITHUB_BASE_REF (expected to be set by github to the target branch == main).
So from the scanner point of view, this is undefined behavior.
I would suggest that you remove this property completely from the scanner, and you should get the expected behavior.
Out of curiosity, is there a reason you are analyzing PRs when they are flagged as closed?
This would mean that while the PR is alive, you do not analyze the new code. So you will only know of new issues, duplication, and missing coverage after the merge has happened.
And it is working only when ‘whatever’ branch is long-lived, with short-lived branches I also have few lines of code because I can’t set the sonar.branch.target properly as it could different for each branch.
We did the sonar scan on the pull request closed because we could analyse all target branches, when all PRs were merged, even in feature branches. with the current change I can only scan branches set in the GHA.
We also included
if: github.event.pull_request.merged == true
to be sure that the PR was merged and not only closed. For us it was a better way to work, as we could analyse the PRs while working (done in Jenkins), and also analyse the result after merged.
I am still a bit confused about why you are setting the branch variables manually.
Both in jenkins and in github actions, there is some logic to automatically detect if the analysis is running in PR context or not.
For github, if you have both push:branches and pull_request workflow triggers, you will get analysis.
For pushes, it will be a full, normal analysis (slightly slower) and for PRs you will enjoy faster times because of incremental analysis.
I would suggest to completely remove the logic that sets the variables manually.
Please let me know if I am missing something.
I don’t want sonar no do whatever it automatically detects. I want Sonar to do what I want, and in some cases I doesn’t.
I don’t understand why where or when I execute Sonar is more important that what I’m telling sonar to do.
Sonar has parameters so we use them to tell the Scanner what kind of analysis we want. The documentation is confusing, because you can think that you can tell Sonar what kind of analysis you want, but is not true. Sonar decides based of environment variables and not in the parameters explicitly given.
I think you should change the documentation for the users to know the precedence of the parameters versus the environment variables. Or provide a way to override the environment variables as it worked before.
First of all, sorry for the delay.
I would like to clear something that you mentioned:
The scanner prioritizes the parameters (sonar.pullrequest.base and friends) over environment variables.
So if you set the parameters, the environment variables are ignored.
The environment variables are used as fall-back, since most users are in the mainstream CI providers (github, jenkins, etc) and we can do the detection for them out-of-the-box.
For users that are on a different, more niche CI provider, they have to provide it manually.
The purpose of the feature and these parameters are to make Pull Request analysis faster.
If you are using it in a different setting, the caching mechanism might not work.
If I am missing something, please let me know.
It would be most helpful if you could share the values you set to all three of these parameters, as well as the verbose logs of a run after merging from branch1 to branch2 .
I think I have a better idea of what your problem is about now.
My previous answer is about PR Analysis, which I now understand is not what you are trying to do.
I will create an issue for a proper fix.
Until then, could you please try to add this parameter:
