How to Add New Quality Gate Definition in Azure DevOps Pipeline via YAML file

  • ALM => Azure DevOps
  • CI system => Azure DevOps
  • Languages of the repository =>DotNet

ISSUE :
I recently created a custom quality gate definition and manually assigned it to my project via the sonarcloud portal. However, I noticed that when I run the pipeline, the custom definition is only applied to long-lived branches. For short-lived branches, it defaults to SonarCloud’s configuration.

Could someone guide me on how to ensure that my custom quality gate definition is consistently applied across both long-lived and short-lived branches after running YAML pipeline?

also instead of adding project to quality gate definition from portal how to add with azure-pipeline.yml script

Hey there.

Why do you think that is? Can you share screenshots or other information?

Any Quality Gate applied to the project should apply to both short and long-lived branches.

You cannot. This is assigned via the UI only.

Hi Colin,

Thank you for your response.

As requested please find below screenshot

In this screenshot, a rule has been applied to the long-lived branch, causing it to fail. However, when the same code is run from the short-lived branch, it passes because the SonarWay default configuration is applied.
NOTE : for testing purposes, I intentionally added some false rules to ensure that my pipeline fails.

Question: I need to change the long-lived branch pattern for all projects. However, updating each project manually one by one seems complicated. Is there a way to pass this configuration via the YAML pipeline or set this new rule as the default?

Screenshot 02:

  • Project 01

  • Project 02

A short-lived branch only analyzes new code in the branch, so it’s not unheard of that the Quality Gate would be different on an SLB (where only conditions on new code are evaluated) compared to an LLB (where conditions on new and overall code are evaluated).

No, this must be set per-project in the UI.

Hi Colin,

Thank you for your prompt response.

I followed your suggestion to set up a new custom rule that should apply to both short-lived and long-lived branches. However, I encountered an issue: the rule seems to be working only on long-lived main/master branches. Let me provide more details:

  1. Scenario 1:
    • The code is identical in both the Main branch and the Bugfix branch.
    • However, the custom rule is only being applied to the Main branch (which is a long-lived branch).
    • I’ve attached a screenshot showing this behavior.
      (expected output : on both the branches (main and bugfix ) it should fail )

  1. Scenario 2:
    • Even after adding the Bugfix branch to the long-lived branch category, I’m not seeing the expected results similar to the Main branch.
    • The rule doesn’t seem to be enforced consistently across both branches.
    • Another screenshot illustrating this situation is included.
      (expected output : same as main branch it should fail on bugfix branch as well)

Again, it really all depends on what conditions are failing, and what is being categorized as New vs. Overall code. Just scanning a branch once is not going to produce identical results (because a second scan is always required to calculate a Quality Gate on a long-lived branch, and because what lines of code are identified as new might be different).

What I would suggest is that you drill into the specific branch, and see if the measures calculated should or shouldn’t be failing the quality gate based on your quality gate definition. THe measures tab of the long-lived branches should help.