How to make Quality gate fail on obsolete / marked object usage

SonarQube Cloud
, ,
1

How to Fail a Quality Gate on Increased Usages of Obsolete Attributes in New Code?

ALM Used

Azure DevOps

CI System Used

Azure DevOps Pipelines

Languages of the Repository

C# (using .NET Framework 4.8)

Problem Description

We are exploring how to configure SonarCloud to fail the quality gate if new usages of classes marked with [Obsolete] attributes (or custom attributes like [PhaseOut]) appear in pull requests or new code. The idea is to prevent developers from introducing deprecated or unwanted patterns into the codebase.

We understand that SonarCloud does not natively support tracking usages of specific attributes like [Obsolete]. However, we would like guidance on how to implement such a rule effectively.

Steps

  1. Add a new class or method with an [Obsolete] or [PhaseOut] attribute.
  2. Use the class (new or method/prop call)
  3. Push the change as part of a pull request.
  4. Check if the quality gate fails based on the new usage.

Direction so far

We are considering creating a custom Roslyn analyzer to detect the usage of classes marked with [Obsolete] (or custom attribute), generate compiler warnings, and feed those warnings back to SonarCloud. However, we are unsure how to configure the pipeline to pass these warnings as metrics to SonarCloud and use them in a quality gate.

2

Hi, @Jan_Pul, and welcome to the community.

SonarQube does have a C# rule to detect the usage of the Obsolete attribute, but only when it does not provide an explanation message.
I’m curious about the reasoning behind preventing the usage of such an attribute, as deprecating things in in the normal lifecycle of code. Do you have your own attribute you want your developers to use instead?

To answer your question, you can definitely use an analyzer for that. You can simply create an analyzer (and mandate people reference it in their project) and the issues will be surfaced in your analysis with a ROSLYN tag.

Or you can use the SDK we published to wrap your analyzer in a full-fledged SonarQube plugin, but this will only work if you use SonarQube Server (SonarQube Cloud does not support custom plugins at this time). This will allow you to enforce the usage of this analyzer at the SonarQube level, bypassing the need to reference it in the projects.

Denis

3

I wrote my original question reread it once and thought it made sense, it did not so I apologize for that :smile:. I rewrote it

4

Indeed, I now understand what you are trying to achieve, and it could indeed be detected by our analyzers.

I will make a note of that and log it in the backlog for the future!

Denis

5

This would be another rule right? Is it possible to make a quality gate fail on a specific rule? And what kind of timeframe would you imagine for this because my company is planning on spending a sprint on implementing this feature using a custom analyser this quarter.

6

Hi @Jan_Pul,

Here’s how you can use SonarCloud’s generic issue import to detect obsolete class usage, based on the documentation: Generic issue data | SonarQube Cloud Documentation.
@denis.troller, let me know if this makes sense :slight_smile:

1. Define rules and issues in your Roslyn Analyzer:

  • Define rules: Use the documentation to define custom rules within your Roslyn analyzer. Each rule needs an id , name , description , and engineId (a unique identifier for your analyzer).
  • Assign impacts to rules: Define the impacts of each rule in terms of software quality (e.g., MAINTAINABILITY, SECURITY) and severity (HIGH, MEDIUM, LOW).
  • Detect issues: When your analyzer finds an obsolete class usage, generate an issue with these details:
    • engineId of your analyzer
    • ruleId of the corresponding rule
    • primaryLocation (file, line, and column of the usage)
    • message describing the issue

2. Generate a JSON issue report:

  • Report format: Follow the JSON format in the SonarCloud documentation for generic issue import.
  • Report structure: The JSON report has two arrays: rules and issues .
    • rules defines each rule used.
    • issues lists the issues found by your analyzer, each with the details mentioned earlier.

3. Configure import in SonarCloud:

  • sonar.externalIssuesReportPaths parameter: Define this parameter on your CI/CD server to point to the path of the generated JSON file.
  • Execute analysis: Run your project analysis with SonarCloud. The imported issues will appear in the SonarCloud interface.

Example JSON format for an issue:

1{
2  "issues": [
3    {
4      "engineId": "MyCustomAnalyzer",
5      "ruleId": "ObsoleteClassUsage",
6      "primaryLocation": {
7        "filePath": "MyFile.cs",
8        "textRange": {
9          "startLine": 10,
10          "startColumn": 5
11        }
12      },
13      "message": "Usage of the obsolete class 'ObsoleteClass'."
14    }
15  ]
16}

Important:

  • Make sure your analyzer generates issues in the correct JSON format.
  • Test importing issue data into SonarCloud thoroughly to ensure everything works.
  • Remember that the rules you define in your analyzer won’t be visible in SonarCloud. You’ll manage them in your analyzer’s configuration.

Using this approach, you can extend SonarCloud to detect obsolete classes, even without native support.

This is where the story begins :wink:

1 Like
7

Dude you are a lifesaver this looks so good and basically exactly what I am looking for, I’m gonna see if I can make it work tomorrow.

8

This would indeed be a new rule for C#, and it will not happen in the near term, I’m afraid.

You cannot fail a QG on a specific rule, but you can change the severity of a given rule to allow you to consider it as a blocker, for example.

Denis

9

thanks for the conformation! okay ill try the approach Bachri_Abdel suggested, i have one more quick question. How does sonarcloud detect add condition ‘On new code’, does it use the primary location of the generic issue data to check if it is in the git diff?

10

@Jan_Pul,

I hope the new code issues will be well detected. Try it then you can learn more about Sonar new code detection.

11

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.