Add CLI severity override flags: --blocker, --critical, --major, --minor, --info, --ignore

[Copilot]

Adds six CLI flags to override the severity of specific validation codes or suppress them entirely, affecting both exit code behavior and SonarQube JSON report output.

New flags

--blocker  <codes>   BLOCKER  → exit 1
--critical <codes>   CRITICAL → exit 1
--major    <codes>   MAJOR    → exit 1  (unchanged default)
--minor    <codes>   MINOR    → exit 0, shown as (warning)
--info     <codes>   INFO     → exit 0, shown as (info)
--ignore   <codes>   suppress → not shown, excluded from Sonar report

Each flag accepts comma-separated codes (SLNX011,SLNX012) or * for all codes.

Wildcard + specific code priority

Two-pass parsing ensures specific codes always beat *, regardless of flag order:

# SLNX011 stays MAJOR; everything else downgrades to INFO
slnx-validator MySolution.slnx --info * --major SLNX011

# Ignore everything except SLNX013
slnx-validator MySolution.slnx --ignore * --major SLNX013

Key changes

• Program.cs — registers 6 new options; ParseSeverityOverrides uses two passes (wildcards first, specific codes second) so specific entries always win
• ValidatorRunnerOptions — new optional IReadOnlyDictionary<ValidationErrorCode, SonarRuleSeverity?> SeverityOverrides (null = ignore)
• ValidatorRunner — exit code now based on effective severity; only BLOCKER/CRITICAL/MAJOR cause exit 1
• SonarReporter — applies overrides to rule severity in JSON output; excluded ignored codes from rules and issues
• ValidationReporter — suppresses ignored codes from console output; adds (warning)/(info) labels for downgraded codes
• SonarRuleSeverity — changed to public (required by CLI project)

SonarQube report behavior

Override is reflected in the generated rule definition:

{ "id": "SLNX011", "severity": "MINOR", ... }

Ignored codes are excluded from both rules and issues entirely.

Original prompt

Goal

Add CLI options to override the severity of specific validation codes, or suppress them entirely. This allows users to customize how codes are reported — both for exit code behaviour and for the SonarQube JSON report output.

New CLI flags

Add the following six flags to Program.cs:

--blocker  <codes>   Treat specified codes as BLOCKER severity
--critical <codes>   Treat specified codes as CRITICAL severity
--major    <codes>   Treat specified codes as MAJOR severity
--minor    <codes>   Treat specified codes as MINOR severity
--info     <codes>   Treat specified codes as INFO severity
--ignore   <codes>   Suppress specified codes entirely (not shown, not in Sonar report)

Each flag accepts either:

• A comma-separated list of codes: SLNX011,SLNX012
• A wildcard * to match all known ValidationErrorCode values: *

* wildcard — highest priority concern

* must be supported on all flags. When * is provided, it applies the severity to all known ValidationErrorCode enum values.

Combining * with specific overrides must work, and specific code overrides must always win over *:

# All codes set to INFO, except SLNX011 which becomes MAJOR
slnx-validator MySolution.slnx --info * --major SLNX011

To implement this correctly, process flags in order of ascending priority: wildcard * entries first (lowest priority), specific code entries last (highest priority). Within parsing, * should be expanded to all enum values first, then specific codes overwrite them.

A simple way to guarantee specific codes win: sort inputs so * is always processed before individual codes regardless of flag order on the CLI.

Severity → exit code mapping

Severity	Counts toward exit code 1?
BLOCKER	✅ yes
CRITICAL	✅ yes
MAJOR	✅ yes (default)
MINOR	❌ no
INFO	❌ no
ignore (null)	❌ no (not shown at all)

Only BLOCKER, CRITICAL, and MAJOR should cause exit code 1. MINOR and INFO are shown in output but do not fail the build.

Effect on SonarQube report

When --sonarqube-report-file is used together with severity override flags, the overridden severity must be reflected in the generated rule definition in the JSON output:

{
  "id": "SLNX011",
  "severity": "MINOR",   // ← overridden via --minor SLNX011
  ...
}

Codes marked as --ignore must be excluded from both the rules and issues arrays in the Sonar report entirely.

Code changes required

ValidatorRunnerOptions.cs

Add a new property:

IReadOnlyDictionary<ValidationErrorCode, SonarRuleSeverity?> SeverityOverrides
// SonarRuleSeverity? = null means "ignore"

Program.cs

• Register the 6 new options
• Parse them into a Dictionary<ValidationErrorCode, SonarRuleSeverity?> using a helper
• Pass the dictionary into ValidatorRunnerOptions

Parsing helper logic:

static void ParseInto(string? input, SonarRuleSeverity? severity,
    Dictionary<ValidationErrorCode, SonarRuleSeverity?> target)
{
    if (input is null) return;

    if (input.Trim() == "*")
    {
        foreach (var code in Enum.GetValues<ValidationErrorCode>())
            target[code] = severity;
        return;
    }

    foreach (var raw in input.Split(',', StringSplitOptions.TrimEntries | StringSplitOptions.RemoveEmptyEntries))
    {
        var code = ParseCode(raw); // parse "SLNX011" → ValidationErrorCode
        target[code] = severity;
    }
}

Call order in ParseSeverityOverrides — process *-capable flags in ascending priority so specific codes always win. One approach: process all flags once for * values first, then again for specific codes. Another approach: call ParseInto for all flags in a fixed order where * flags are expanded first and named-code flags are applied last. The simplest correct approach:

// Pass 1: wildcards only (expand * for all flags)
ParseWildcardsOnly(blocker, SonarRuleSeverity.BLOCKER, result);
ParseWildcardsOnly(critical, SonarRuleSeverity.CRITICAL, result);
// ... etc for all 5 severities + ignore

// Pass 2: specific codes only (these overwrite pass 1)
ParseSpecificOnly(blocker, SonarRuleSeverity.BLOCKER, result);
ParseSpecificOnly(critical, SonarRuleSeverity.CRITICAL, result);
// ... etc

SonarReporter.cs

• Accept the SeverityOverrides dictionary (inject via method parameter or constructor)
• In GetRuleDefinition or WriteReportAsync, apply the override to the rule's Severity field before serialization
• Filter out ignored codes (where override is null) from both rules and issues

ValidatorRunner.cs

• Pass SeverityOverrides through to where exit code is determined
• When determining if a FileValidationResult has errors that count toward exit 1, filter out errors whose code has a severity override of MINOR, INFO, or null (ignore)

Output / reporter

In ValidationReporter.cs:

• Filtered/ignored code...

This pull request was created from Copilot chat.

---

📍 Connect Copilot coding agent with Jira, Azure Boards or Linear to delegate work to Copilot in one click without leaving your project management tool.