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)
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.
As a developer, I create a new PR on GitHub/BitBucket/VSTS:
- 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
- I review the issue, and finds out that it's a FP or something that I won't fix => I flag it as such
- In SonarQube: I notice that the status of the branch in SonarQube automatically turns to green
- 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
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.
We expect this to be working at SonarSource, with Next and Burgr which push info to GitHub PRs - see