Automatic Issue assignment not working

ankur · April 25, 2024, 10:36pm

ALM used - Azure DevOps
CI system used - Azure DevOps
Scanner command used when applicable (private details masked)
Languages of the repository - C#
Steps to reproduce

  - task: SonarCloudPrepare@1
    displayName: 'Prepare analysis configuration'
    inputs:
      SonarCloud: 'SonarCloud'
      organization: 'XXXORGANISATIONXXX'
      scannerMode: 'MSBuild'
      projectKey: $(sonarProjectKey)
      projectName: $(sonarProjectName)
      extraProperties: |
        sonar.scm.forceReloadAll=true
        sonar.projectVersion: $(Build.BuildNumber)
        sonar.projectBaseDir: ./s

After running the above analysis of code, the “New Issues” are reported to SonarCloud dashboard.

When we see the issues raised in SonarCloud, they appear as “not assigned”.

As per the documentation, the issue is automatically assigned to the last committer. We have checked in SonarCloud and the user committing the code does appear under “Members” of the project.

Some log details:

INFO: Found 122 MSBuild C# projects: 55 MAIN projects. 8 TEST projects. 59 with no MAIN nor TEST files.
INFO: Sensor C# [csharp] (done) | time=16703ms
INFO: Sensor Analysis Warnings import [csharp]
INFO: Sensor Analysis Warnings import [csharp] (done) | time=5ms
INFO: Sensor C# File Caching Sensor [csharp]
INFO: Sensor C# File Caching Sensor [csharp] (done) | time=581ms
INFO: Sensor Zero Coverage Sensor
INFO: Sensor Zero Coverage Sensor (done) | time=693ms
INFO: SCM Publisher No SCM system was detected. You can use the 'sonar.scm.provider' property to explicitly specify it.
INFO: CPD Executor 630 files had no CPD blocks
INFO: CPD Executor Calculating CPD for 1901 files
INFO: CPD Executor CPD calculation finished (done) | time=857ms
INFO: Analysis report generated in 5110ms, dir size=50 MB
INFO: Analysis report compressed in 7589ms, zip size=9 MB
INFO: Analysis report uploaded in 1812ms
INFO: ANALYSIS SUCCESSFUL, you can find the results at: https://sonarcloud.io/dashboard?id=XXXX
INFO: Note that you will be able to access the updated dashboard once the server has processed the submitted analysis report
INFO: More about the report processing at https://sonarcloud.io/api/ce/task?id=XXXXX
INFO: Sensor cache published successfully
INFO: Analysis total time: 3:23.909 s
INFO: ------------------------------------------------------------------------
INFO: EXECUTION SUCCESS
INFO: ------------------------------------------------------------------------
INFO: Total time: 3:39.031s
INFO: Final Memory: 63M/210M
INFO: ------------------------------------------------------------------------
The SonarScanner CLI has finished
20:17:40.832  Post-processing succeeded.
Finishing: SonarCloudAnalyze

Any idea why this feature is not working?

ganncamp · April 26, 2024, 3:49pm

Hi,

First,

I would remove this property. All you’re doing is lengthening analysis duration.

Don’t do this either. By changing the project version string with every build, you’re

ruining your ability to use the ‘previous version’ New Code definition
marking every single build as a new release version and therefore special, and to be retained indefinitely. You don’t care about the (admittedly minor) DB bloat this causes because that’s on our end, but you probably care that it makes rendering your Activity tab slower over time.

Looking at the user’s account, does the ID in the commit match the login the user is using for SonarCloud and/or an SCM Account listed for the user?

Thx,
Ann

ankur · April 29, 2024, 11:25am

Thanks Ann for your feedback. I will pick up the first two points raised. For the last one around ID, we use SSO integration for both Azure DevOps and SonarCloud. Assuming that we are getting same email id to login to both applications, the ID should be same.
Is there anything specific I can look at to compare or check in the logs somewhere?

Thanks for your help!

ganncamp · April 30, 2024, 1:00pm

Hi,

Could you look at the user account in SonarCloud and verify, please?

Thx,
Ann

ankur · April 30, 2024, 1:38pm

I am not sure how to find it. If I try to assign an “Not assigned” issue to myself I can see the user listed like this:

On the “Members” screen, I can see my username as below:

I am not sure why user is not show with email id but that might just be the default behavior.

As I mentioned earlier, we just use SSO login so I assume that if both systems are not configured correctly to work, I should not be able to sign in at first place. Hope that makes sense.

Thanks!

ganncamp · April 30, 2024, 2:31pm

Hi,

Can you check an issue you know you created, and see if the blame data you get when you click next to it in the left margin shows the same user name as your screenshot above, please?

Thx,
Ann

ankur · April 30, 2024, 3:22pm

Hi Ann,

Just to confirm, are you talking about the SonarCloud application? Not too sure what you mean by “click next to it in the left margin”. Any screenshot or guidance will help me understand this better.

Thanks!

ganncamp · April 30, 2024, 3:34pm

Hi,

Here you go:

HTH,
Ann

ankur · April 30, 2024, 8:29pm

Thanks. I use gitExtensions and I can see the same user name at both places (i.e. gitExtensions and SonarCloud) for the last change I built for and the issue showing up in the SonarCloud. The issue still remains unassigned. What else can I try?

ganncamp · May 1, 2024, 11:28am

Hi,

Please go into SonarCloud, select an issue, and click in the margin to its left. Then compare the Author you see there with the user account in SonarCloud.

Thx,
Ann

ankur · May 1, 2024, 12:08pm

Hi Ann,

Thanks for the clarification. Unfortunately I don’t see any Author or commit hash details as you shared with your sample screenshot.

I also checked for another issue but similar type of problem persists. Is this information failing to get synced to SonarCloud? How can we check further details?

Thanks!

ganncamp · May 1, 2024, 12:14pm

Hi,

Okay, this is the problem; it looks like analysis doesn’t have full access to the blame data.

Aaand… now I see what I missed in your initial post:

BTW, don’t use that property; it doesn’t work. I’ve tried to get that message removed - so far unsuccessfully.

So… let’s talk about how your source code gets into the directory where analysis takes place. You should be checking out into the workspace and then analyzing there, side-by-side with the SCM metadata. That makes the SCM blame data available to analysis for things like proper issue dating and assignment.

HTH,
Ann

ankur · May 1, 2024, 1:27pm

Thanks Ann for your help so far and prompt answers. I am not sure “analysis doesn’t have full access to the blame data” means?
As you explained in detail how SonarCloud analysis works, I am not too sure if we can do anything about controlling the behavior of checkout of code since its all happening on Azure hosted build agents. Also if I may share the below logging from one of our projects pipeline for scanning and analysis, you can see that it looks working fine (other than the SCM warning message):

> INFO: Sensor Zero Coverage Sensor
> 
> INFO: Sensor Zero Coverage Sensor (done) | time=688ms
> 
> INFO: SCM Publisher No SCM system was detected. You can use the 'sonar.scm.provider' property to explicitly specify it.
> 
> INFO: CPD Executor 630 files had no CPD blocks
> 
> INFO: CPD Executor Calculating CPD for 1909 files
> 
> INFO: CPD Executor CPD calculation finished (done) | time=1109ms
> 
> INFO: Analysis report generated in 4086ms, dir size=50 MB
> 
> INFO: Analysis report compressed in 7476ms, zip size=9 MB
> 
> INFO: Analysis report uploaded in 1954ms
> 
> INFO: ANALYSIS SUCCESSFUL, you can find the results at: https://sonarcloud.io/dashboard?id=XXXX-Solutions_XXXXX
> 
> INFO: Note that you will be able to access the updated dashboard once the server has processed the submitted analysis report
> 
> INFO: More about the report processing at https://sonarcloud.io/api/ce/task?id=AY8wq06LzAUBdJL0Si_m
> 
> INFO: Sensor cache published successfully
> 
> INFO: Analysis total time: 3:40.478 s
> 
> INFO: ------------------------------------------------------------------------
> 
> INFO: EXECUTION SUCCESS
> 
> INFO: ------------------------------------------------------------------------
> 
> INFO: Total time: 4:08.435s
> 
> INFO: Final Memory: 255M/854M
> 
> INFO: ------------------------------------------------------------------------
> 
> The SonarScanner CLI has finished
> 
> 20:21:32.225 Post-processing succeeded.

Please suggest how can I proceed next?

Regards,

Ankur

ganncamp · May 1, 2024, 2:13pm

Hi,

I see the same line in the log snippet you’ve just supplied:

Ehm…
How does the code get to the build agent?
Do you build / analyze in the checkout directory, or is there some cd-ing in there?

Ann

ankur · May 1, 2024, 3:02pm

Hi Ann,

Yes that’s correct. The build agent checks out code on the MS hosted VMs (much beyond our control as its a SaaS). That being said, we have done the setup following instructions from SonarCloud documentation..

The other documentation does talk about SCM integration and possible issues around issues not being assigned automatically, but doesn’t say anything specifically about Azure DevOps

Thanks!

ganncamp · May 1, 2024, 3:04pm

Hi,

You keep saying you have no control over the checkout…

But you own the pipeline script. That’s what makes checkout happen.

Ann

ankur · May 1, 2024, 3:48pm

When I say we have no control, I mean we can’t connect to the agent to see what’s being checked out in workspaces.
Also, if you are familiar with Azure DevOps YML based pipelines, you can see how little we actually control. Meaning we can only configure the “Tasks” in the YML pipeline. Something like below we have done for one of our pipeline:

trigger:
- development

pool:
  vmImage: ubuntu-latest
variables:
  - name: SonarProjectName
    value: Infrastructure
  - name: SonarProjectKey
    value: KEYVALUE
  - name: AGENT_USE_NODE10
    value: true

# Please put your actual values in variables
steps:
  - task: SonarCloudPrepare@1
    inputs:
      SonarCloud: 'SonarCloud'
      organization: 'MY ORG'
      scannerMode: 'CLI'
      configMode: 'manual'
      cliProjectKey: '$(SonarProjectKey)'
      cliProjectName: '$(SonarProjectName)'
  - task: SonarCloudAnalyze@1
    displayName: SonarCloud Scan
  - task: SonarCloudPublish@1
    displayName: SonarCloud Publish
    inputs:
      pollingTimeoutSec: '300'

Are there any additional configurations that you would expect to have in place for SCM?

Thanks!

ganncamp · May 1, 2024, 3:53pm

Hi,

I’ll admit that this is certainly not my area of expertise. But I think Microsoft can help.

Ann

ankur · May 5, 2024, 3:01pm

Hi Ann,

Thanks for your help. Actually your last message put me in right direction since I was able to fix the problem by adding fetchDepth: 0 property to the .yml pipeline.
It appeared that the issue was caused by missing blame data information (as you earlier mentioned) and I was able to pull that data by setting above property.
There was another problem caused by wrong location for the base directory for Sonar analysis which once corrected, showed issues correctly assigned in SonarCloud.

Thanks for all your help and I learnt a lot during this troubleshooting.

Ankur