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.

            People

            Assignee:
            baymac Parichay Barpanda
            Reporter:
            tgr Tobias Gruetzmacher
            Votes:
            3 Vote for this issue
            Watchers:
            4 Start watching this issue

              Dates

              Created:
              Updated: