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

Improve issue tracking between branches and PRs

    Details

      Description

      WHY

      At SonarSource, we are frequently developing with this pattern:

      master
        \- feature/MMF-xxx/common-branch
            \- feature/jh/MMF-xxx/fix-foo
            \- feature/sb/MMF-xxx/do-bar
      

      A common feature branch is created for a sprint. We usually open a PR between this common branch feature/MMF-xxx/common-branch and long living branch master to have a global vision of the quality of the common branch. In some cases, it can also be changed to a SLB analysis.
      Then developers create their own short lived branches for their individual tasks, and open PRs for peer review, targeting the common branch.

      In SonarQube, we made the choice to attach all PRs/SLBs to a long living branch.
      Since the common branch is not a long living branch, the model rather looks like the following:

      master
        \- feature/MMF-xxx/common-branch
        \- feature/jh/MMF-xxx/fix-foo
        \- feature/sb/MMF-xxx/do-bar
      

      And issue tracking is made only between the analyzed PR/SLB and the long living branch.
      To keep track of issues after the merge of a PR/SLB, when analyzing a long living branch, we are looking at all attached PRs/SLBs to see if the same issue was not already reported and flagged as WF/FP/confirmed and, in that case, we copy the issue attributes .

      But, this the mechanism, we currently don't track issues properly.
      Several issues:

      1. If I introduce an issue in my personal SLB/PR, mark it as WF and merge in the common branch, the issue status is not copied and the same issue appear again as open in the common branch.
      2. Then if my teammates create a new personal SLB/PR or rebase their branches on the common branch, they may start seeing the same issue in their branch (assuming they touched the same file).

      WHAT

      We should improve the issue tracking to always:

      • show in a SLB/PR only the issues injected in this branch/PR, even when the target branch is not analyzed in SonarQube
      • always preserve WF/FP/confirmed status when a PR/SLB is merged into another branch

      And this should work whatever the type of branch, even when the target is a short-lived branch.

      HOW

      • In case a branch is analyzed:
        1. When analyzing a PR/SLB targeting this branch:
          2 strategies:
          • The first option that is the most accurate:
            [Extend regular issue tracking with a 3 ways issue tracking] Hide issues that already exist in the direct target branch, not only at the ones in the base and the final long living branches.
          • Fallback if the first option brings to much complexity:
            [Filter issues on top of regular issue tracking] Only report issues on changed lines (not changed files), as if the final long living branch is not analyzed.
        2. [Apply light issue tracking to PR/SLBs] When analyzing this branch, always apply the same "merge" principle as we already do for long living branches and this way preserve issue status from all PR/SLBs that target directly the same long lived branch.
          Also, when analyzing a PR created from this branch, copy WF/FP/confirmed status of issues from this base branch.
          To handle the cases where the issue status changes several times in a PR or the issue appears in several PR/SLBs, issue tracking will now keep the status of the most recently updated match.
          With this mechanism, issue states will be automatically propagated across all the branches/PRs.
      • In case a branch is NOT analyzed:
        1. When analyzing a PR/SLB targeting this branch, only report issues on changed lines (not changed files), as if the final long living branch is not analyzed. When analyzing the final long living branch, issue tracking should then naturally work

      We'll take this opportunity to also show the correct target of PRs, by storing and displaying the targeted SLB.

      Notes about how it works:

      • branch name: name of the current analyzed branch or source branch for a PR
      • main branch: the default long living branch. The default target for SLB and PR
      • target branch: target/base branch for a PR (where the PR will be merged). For a short living branch, it's most of the time unknown, except if user provides it on command line
      • reference (long living) branch: computed by looking transitively for target branches (default to main branch). All PR/SLB "attached" to the same reference branch will have issue tracking between them

      For a PR, we expect the user to merge <branch name> into <target branch>

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                christophe.levis Christophe Levis
                Reporter:
                julien.henry Julien Henry
              • Votes:
                1 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: