Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-61320

MR status doesn't replace branch status

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Labels:
      None
    • Environment:
      Jenkins ver. 2.204.2
      gitlab-branch-source-plugin 1.4.4
    • Similar Issues:

      Description

      Consider a branch source job with the following configuration:

      • Discover branches: Only branches that are not also filed as MRs
      • Discover merge requests from origin: Merging the merge request with the current target branch revision

      Scenario:

      1. A user pushes a branch
        • A new job is created for the branch
        • The branch is built, but the build fails
        • The plugin pushes a "failed" status with name "jenkinsci/branch" to GitLab
      2. The user creates a merge request
        • A new job is created for the merge request
        • The branch job is disabled
        • The MR job is built and also fails
        • The plugin pushes a "failed" status with the name "jenkinsci/mr-head" to GitLab
      3. User realizes the build is broken and fixes a bug in the build system (not sure if this is only a problem if the HEAD of the branch doesn't change of if that always happens)
        • The MR job is built and is now successful
        • The plugin pushes a "passed" status with the name "jenkinsci/mr-head" to GitLab

      The result is now a merge request which is still considered as "failed" by GitLab, because the Job "jenkinsci/branch" will forever be "failed":

        Attachments

          Activity

          Hide
          phihos Philipp added a comment -

          Hi, I am affected by this as well and would like to help out. Before getting to work I would like to discuss the solution.
          How I see it we have two possibilities:

          1. Updating "jenkinsci/branch" to status "success" as well when setting "jenkinsci/mr-head". to success. The link should also be updated to point to the MR pipeline to prevent 404.
          2. Deleting the "jenkinsci/branch" pipeline after "jenkinsci/mr-head" is created in GItlab as pending. Doing this after and not before is important to prevent "merge when pipeline succeeds" to trigger before "jenkinsci/mr-head" has blocked the merge.

          Any opinions which way to go? Maybe a third way I have not thought of? I currently prefer option 2 because it is more true to the actual state: The branch pipeline does not exist anymore so it should not be displayed. Option 1 might cause confusion.

          Show
          phihos Philipp added a comment - Hi, I am affected by this as well and would like to help out. Before getting to work I would like to discuss the solution. How I see it we have two possibilities: Updating "jenkinsci/branch" to status "success" as well when setting "jenkinsci/mr-head". to success. The link should also be updated to point to the MR pipeline to prevent 404. Deleting the "jenkinsci/branch" pipeline after "jenkinsci/mr-head" is created in GItlab as pending. Doing this after and not before is important to prevent "merge when pipeline succeeds" to trigger before "jenkinsci/mr-head" has blocked the merge. Any opinions which way to go? Maybe a third way I have not thought of? I currently prefer option 2 because it is more true to the actual state: The branch pipeline does not exist anymore so it should not be displayed. Option 1 might cause confusion.
          Hide
          tgr Tobias Gruetzmacher added a comment -

          I, too, would prefer something like solution 2.

          Show
          tgr Tobias Gruetzmacher added a comment - I, too, would prefer something like solution 2.
          Hide
          p_hampson Paul "TBBle" Hampson added a comment -

          I'd prefer option 2 as well. I'd expect as part of this that the branch would be considered 'gone' from the Jenkins view, as there is now an MR for it. This is how the Helix Swarm Branch Source in the P4 plugin works, it ignores branches which are covered by a review, and Jenkins Multi-branch Pipeline then marks those builds as disabled and eventually deletes them.

          This would also be how JENKINS-61138 could work, since if an MR is ignored, its branch should still be visible.

          Show
          p_hampson Paul "TBBle" Hampson added a comment - I'd prefer option 2 as well. I'd expect as part of this that the branch would be considered 'gone' from the Jenkins view, as there is now an MR for it. This is how the Helix Swarm Branch Source in the P4 plugin works, it ignores branches which are covered by a review, and Jenkins Multi-branch Pipeline then marks those builds as disabled and eventually deletes them. This would also be how  JENKINS-61138 could work, since if an MR is ignored, its branch should still be visible.
          Hide
          shababqaisar Shabab added a comment -

          I am also affected by this.

          In my case I'm using remote JenkinsFile using the `remote-file` plugin so I see two problems.

          1. It only shows single stage in gitlab named `jenkins/branch` for branches and `jenkins/mr-head` for merge requests

          2. Branch names are incorrect.

          Shouldn't these be stages name?
          I'm using Plugin's Version: 1.5.8

          Show
          shababqaisar Shabab added a comment - I am also affected by this. In my case I'm using remote JenkinsFile using the `remote-file` plugin so I see two problems. 1. It only shows single stage in gitlab named `jenkins/branch` for branches and `jenkins/mr-head` for merge requests 2. Branch names are incorrect. Shouldn't these be stages name? I'm using Plugin's Version:   1.5.8

            People

            Assignee:
            surenpi Rick
            Reporter:
            tgr Tobias Gruetzmacher
            Votes:
            5 Vote for this issue
            Watchers:
            6 Start watching this issue

              Dates

              Created:
              Updated: