Details

    • Type: MMF
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Labels:

      Description

      Why

      Users currently have too many options when configuring their Quality Gates. For instance, they confuse themselves (and us!) with "on Leak Period=true" Quality Gate / Webhook payloads with negative values and operators that don't make sense.

      What

      We'll drop

      • the 'on new code' checkbox which can result in confusing negative differential values in webhook payloads. In most cases, the "New" metrics are what's really needed.
      • the ability to set warnings
      • the ability to choose from a range of operators on a condition. Instead, we'll hard code "greather/less than" as appropriate for metrics with a non-zero direction (e.g. Line Coverage), and offer "less than"/"greater than" for metrics with a zero direction (e.g. Conditions to Cover on New Code).
      • the ability to set conditions on metrics of these types: BOOLEAN, STRING, DATA, DISTRIB

      This implies a migration for Quality Gate conditions currently using options we'll remove.

      • Warnings will simply be dropped
      • For "on new code" conditions, the conversion to "New" metrics is obvious where those are available.
      • For "on new code" conditions where no "New" metric is available we will drop the condition
      • We'll drop conditions on metrics of types BOOLEAN, STRING, DATA, DISTRIB
      • We'll drop conditions that don't already use supported operators:
        Direction < > == !=
        0 keep keep drop drop
        -1 (e.g. Blockers) drop keep drop drop
        1 (e.g. Coverage) keep drop drop drop
      • We'll fix operators on "Conditions to cover" (only > will be supported) and "Unit tests" (only < will be supported)

      Project Migration
      Project measures, history, events will not be updated. Project currently in Warning status will naturally move to Green on next analysis (assuming the quality doesn't nosedive).

      In 9.0 we'll drop warnings from measure history and from events. Maybe. At any rate, we can drop code supporting warnings at this point.

      How

      Kanban: https://jira.sonarsource.com/secure/RapidBoard.jspa?rapidView=176

      Docs

      We'll add a note in the documentation of the metric definition about Warning status being removed in 7.x

      On UI side

      • drop "On New Code" and "Warning" columns in the table of conditions
      • drop "On New Code" checkbox and "Warning" input field in the condition form
      • restrict the list of available operators in the condition form (see "What" for details)

      On WS side

      • POST api/qualitygates/create_condition
        • Remove parameter period
        • Remove parameter warning
        • Fail when parameter op is set to an unsupported value (See "What" for details)
      • POST api/qualitygates/update_condition
        • Remove parameter period
        • Remove parameter warning
        • Fail when parameter op is set to an unsupported value (See "What" for details)
      • GET api/qualitygates/show
        • Remove "period" from the response
        • Remove "conditions"."warning" from the response
      • GET api/qualitygates/project_status
        • Deprecate "warning" from the response
      • GET api/qualitygates/application_status
        • Deprecate "warning" from the response

      On CE side

      Remove computation of differential measures (ComputeMeasureVariationsStep)

      On DB side

      Warning, the following migrations must only be done after the previous web services have removed, and deployed on SonarCloud (In order to be B/G compatible).

      • Update all quality gate conditions that were using warning, period, and no more supported operations
      • Drop column QUALITY_GATE_CONDITIONS#VALUE_WARNING
      • Drop column QUALITY_GATE_CONDITIONS#PERIOD

      Nice to have, to be investigated :

      • The removal of computation of differential measures may give the opportunity to stop using VARIATIONS columns.
      • The idea would be to move the persistance of leak value of measures on new code (new_XXX measures) in LIVE_MEASURES#VARIATION / PROJECT_MEASURES#VARIATION_VALUE_1, to store them in LIVE_MEASURES#VALUE / PROJECT_MEASURES#VALUE
        => Investigate impact in CE and WS

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                christophe.levis Christophe Levis
                Reporter:
                christophe.levis Christophe Levis
              • Votes:
                2 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: