Uploaded image for project: 'Product Roadmaps'
  1. Product Roadmaps
  2. MMF-988

Manual changes on issues of short-lived branches must trigger the webhook call



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


      MMF-969 and MMF-972 are considered as being some pre-requisites before implementing this MMF.

      We consider that:

      • MMF-969 (short lived branches) is used to analyse pull requests (which is what is done internally on Next)
      • A mechanism is implemented to listen to the SonarQube webhooks in order to update the status of the pull requests on the external system - like GitHub, BitBucket, VSTS, ... (which is what should be done soon on Burgr)

      The Problem

      Thanks to the webhook that is called at the end of the processing of a report for a short lived branch, the home-made mechanism will automatically update the pull request related to the short lived branch that has just been analysed. This is good, but not enough.

      Indeed, if a developer finds a false-positive and flags it in the short lived branch in SonarQube, nothing is triggered on CE side. This means that the webhook is not called, and therefore the external system can't be updated to reflect that change. This change will be only available when (or "if") there's a new analysis of the pull request.

      Use Case

      As a developer, I create a new PR on GitHub/BitBucket/VSTS:

      1. A few minutes later, I get a notification from SonarQube that one issue was found on that PR => I click on the link and indeed notices that the related branch is red
        • If I go on GitHub/BitBucket/VSTS, I also see that the status is red
      2. I review the issue, and finds out that it's a FP or something that I won't fix => I flag it as such
      3. In SonarQube: I notice that the status of the branch in SonarQube automatically turns to green
      4. I go to GitHub/BitBucket/VSTS: I notice that the status of the PR also turned to green, and I can merge w/o having to restart an analysis

      The Solution

      Each time there's a manual modification (in the Web UI) of 1 issue or several issues (bulk change) of a short branch, if this change impacts the status of the short branch, then the webhook should be called - just like it is currently done at the end of the compute engine.

      By "status", we mean:

      • the green or red color of the short branch
      • the distribution of unresolved issues per type

      Manual operations that impact the status of a branch (and so which should trigger the webhook call):

      • An issue is resolved (as fixed, FP or won't fix)
      • An issue is reopened
      • The type of an issue is changed

      Note: in case of bulk change, only one web hook call should be done.

      The validation

      We expect this to be working at SonarSource, with Next and Burgr which push info to GitHub PRs - see MMF-1068.


          Issue Links



              freddy.mallet Freddy Mallet (Inactive)
              freddy.mallet Freddy Mallet (Inactive)
              2 Vote for this issue
              5 Start watching this issue