Template for a good new topic, formatted with Markdown:
- ALM used (GitHub)
- CI system used (Github actions)
- Scanner command used when applicable (private details masked)
...
# SonarCloud scan
- name: SonarCloud Scan
uses: SonarSource/sonarcloud-github-action@master
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # Needed to get PR information, if any
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
...
- Languages of the repository
Typescript
- Error observed (wrap logs/code around with triple quotes ``` for proper formatting)
WARN: External issues were imported with a deprecated format which will be removed soon. Please switch to the newest format to fully benefit from Clean Code: https://docs.sonarcloud.io/enriching/generic-issue-data/
Hello there, similar question as this now closed topic External issues report deprecated format
I’m integrating sonarcloud into our company’s repo, it’s a react, angular and nodejs web application
I’ve added external ESLint report analysis, the report is post-processed to the generic issue format but I’m getting this warning.
It’s not clear to me how to move from the now deprecated generic issue format to the new clean code attributes. The documentation only explains the principles but nothing regarding actual implementation.
In the closed topic I mentioned apparently there’s a problem regarding the release of this new format, if that’s the case do you have any update on it ?
I’m worried that I’m investing time in the deprecated format and it will be pulled out soon (btw when is it supposed to be removed ?)
Thanks in advance!
2 Likes
Hi @Ayoub_Moujane, thanks for raising this. We published the docs today so you should find what you’re looking for on the Generic Issue Data page 
. Hope this helps!
Tony
Hi Tony, thanks I’ll look into it ! 
I switched to the new format 
, I still have a question. In sonarCloud the issues are classified into 4 categories (cf: screenshot)
My generic issue appears as a vulnerability which doesn’t really make sense, do I have control over this classified with the new generic error format ?
Here’s an example of my generated issues
{
"rules": [
{
"id": "@typescript-eslint/ban-ts-comment",
"name": "Ban TS Comment",
"description": "Disallow the use of TypeScript type assertions",
"engineId": "eslint",
"cleanCodeAttribute": "LOGICAL",
"impacts": [
{
"softwareQuality": "RELIABILITY",
"severity": "HIGH"
}
],
"effortMinutes": 15
}
],
"issues": [
{
"engineId": "eslint",
"ruleId": "@typescript-eslint/ban-ts-comment",
"primaryLocation": {
"message": "Do not use \"@ts-ignore\" because it alters compilation errors.",
"filePath": "xxxxxx.ts",
"textRange": {
"startLine": 6,
"endLine": 6,
"startColumn": 0,
"endColumn": 12
}
},
"effortMinutes": 15
},
{
"engineId": "eslint",
"ruleId": "@typescript-eslint/ban-ts-comment",
"primaryLocation": {
"message": "Do not use \"@ts-ignore\" because it alters compilation errors.",
"filePath": "xxxxxx.ts",
"textRange": {
"startLine": 8,
"endLine": 8,
"startColumn": 0,
"endColumn": 12
}
},
"effortMinutes": 15
},
...
]
}
Hi @Ayoub_Moujane
Normally, your issues should be classified as Reliability, as you provided the RELIABILITY impact.
Could you check if the rules that you defined have only one impact defined? In case there are more impacts, we’ll take the first one to determine the type.
Otherwise, we’ll need a bit more information in order to investigate the problem, could you provide us with:
- organization and project key
Let us know, in case the project is private, and I’ll contact you in a private message to get this info then.
Anita
Hi Anita,
Sorry for the delayed response, I’ve been on other tasks, I’ll get back on this topic in the following days,
In the meantime I can confirm that the rules have only one impact defined and the project is private
Hi @Ayoub_Moujane ,
I contacted you in a private message to get the project details.
Anita
