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

MR status doesn't replace branch status

    XMLWordPrintable

Details

    • Bug
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • None
    • Jenkins ver. 2.204.2
      gitlab-branch-source-plugin 1.4.4

    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

          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.

          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.

          I, too, would prefer something like solution 2.

          tgr Tobias Gruetzmacher added a comment - I, too, would prefer something like solution 2.

          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.

          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.
          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

          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

          I would prefer option #2 as well. Does anyone affected have a workaround for this issue?

          jkarakashian John Karakashian added a comment - I would prefer option #2 as well. Does anyone affected have a workaround for this issue?

          A solution to this problem is implemented here: https://github.com/jenkinsci/gitlab-branch-source-plugin/pull/177

          cobexer Ing. Christoph Obexer added a comment - A solution to this problem is implemented here: https://github.com/jenkinsci/gitlab-branch-source-plugin/pull/177
          p_hampson Paul "TBBle" Hampson added a comment - - edited

          If I understand correctly, the change in https://github.com/jenkinsci/gitlab-branch-source-plugin/pull/177 only fixes this if you set the option (newly introduced there) to completely overwrite the name of the pipeline with the current "custom prefix" option's value. The new checkbox is off by default.

          And if the special build variables support idea is implemented, the problem would come back if you used, e.g. ${BUILD_NUMBER} because that'd be different between builds, and so you'd be back to old statuses hanging around causing issues. (${BUILD_NUMBER} might be an incorrect usage there, since you probably don't want different pipeline jobs for multiple runs of the same build.)

          So I'd say this problem isn't solved by that (good) change, but it certain offers a clear workaround.

          p_hampson Paul "TBBle" Hampson added a comment - - edited If I understand correctly, the change in https://github.com/jenkinsci/gitlab-branch-source-plugin/pull/177 only fixes this if you set the option (newly introduced there) to completely overwrite the name of the pipeline with the current "custom prefix" option's value. The new checkbox is off by default. And if the special build variables support idea is implemented, the problem would come back if you used, e.g. ${BUILD_NUMBER } because that'd be different between builds, and so you'd be back to old statuses hanging around causing issues. ( ${BUILD_NUMBER } might be an incorrect usage there, since you probably don't want different pipeline jobs for multiple runs of the same build.) So I'd say this problem isn't solved by that (good) change, but it certain offers a clear workaround.

          People

            surenpi Rick
            tgr Tobias Gruetzmacher
            Votes:
            6 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

              Created:
              Updated: