Strange warning when using Azure DevOps extension for SonarCloud

typescript
sonarcloud
vsts

(Thomasdcses) #1

I’m getting the following warning in my logs during the Analyze step when using the SonarCloud extension on Azure DevOps:

Property 'sonar.abap.file.suffixes' is not declared as multi-values/property set but was read using 'getStringArray' method. The SonarQube plugin declaring this property should be updated.

I’m using the YAML definition of the Sonar tasks. These are the versions I’m using (should be the latest):

  • SonarSource.sonarcloud.14d9cde6-c1da-4d55-aa01-2965cd301255.SonarCloudPrepare@1
  • SonarSource.sonarcloud.ce096e50-6155-4de8-8800-4221aaeed4a1.SonarCloudAnalyze@1
  • SonarSource.sonarcloud.38b27399-a642-40af-bb7d-9971f69712e8.SonarCloudPublish@1

The project is written in Typescript and HTML (Angular), so no ABAP code is involved here.

How can I resolve this warning?


(Fabrice Bellingard) #2

Hi,

this is a bug on our side, and we have a ticket to fix this. Unfortunately, there is nothing you can do about this for now - but just ignore this warning.


(Bryan M) #3

Hi Fabrice,

Any update on this issue and when a fix for Sonar Cloud can be expected or a link to a public issue ticket to track?


(Fabrice Bellingard) #4

This is not planed yet, and the ticket is SONARABAP-393


(Andrew) #5

This bug surfaced for me on SFDC Apex code. I have found a workaround that allows the Azure DevOps build to complete.
For my on-prem SQ server, I moved the ABAP .jar file out of the dir and into a bak dir. Restarted SQ server processes and good to go.


(Andrew) #6

Hi,

We are having this issue too. You say to just ignore the warning, but the analysis fails and won’t post the results from VSTS to SonarCloud until this is resolved. Unless I am missing something? Is there a way to force it to ignore these warnings?

Unfortunately our use of Sonar is effectively stopped until this is resolved, even though I am paying a fee for SonarCloud.

Thanks, Andrew.


SonarCloud fails with known error
(Fabrice Bellingard) #7

This issue is now fixed in production.