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

Bitbucket PRs are blocked by excluded branches not being able to report progress

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      The recent Bitbucket behaviour is great but sadly the option of exclude branches that are filed as PRs is blocking PRs from being merged since the branch might be building and report as in progress and never actually finish because it is now being excluded from reporting.

        Attachments

          Issue Links

            Activity

            Hide
            vollmilch Benjamin Fuchs added a comment - - edited

            We are also having a problem with this issue.

            1. There is a "branch" build of the "branch" job running
            2. While its running a pull request is opened for that branch.
            3. Multibranch scanning gets triggered.
            4. The PR gets a "PR" project and a "PR" build starts running.
            (5. I guess the Multibranch scanning has to be triggered again.)
            6. Now the "branch" project gets disabled while the "branch" job is still running.

            The "branch" build will now never update its status to Bitbucket.
            This is a major issue, since the developer cannot merge its PR due to a running job.

            I found out that this line is the problem when updating the status at the end of the job:
            https://github.com/jenkinsci/bitbucket-branch-source-plugin/blob/3412b4eb5b35b9ade7a4e6cfafcdbf3375789fcb/src/main/java/com/cloudbees/jenkins/plugins/bitbucket/BitbucketBuildStatusNotifications.java#L101

            s is of type NullSCMSource and I guess it is due to the branch being removed from "sources" in:
            https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/MultiBranchProject.java

            I create a workaround for us since this was a blocker:
            https://github.com/benjaminfuchs/bitbucket-branch-source-plugin/tree/JENKINS-45643

            If there will be now "quickfix" I guess at least the description in the job config should be updated to pointing to this issue so it is clear to a new user choosing this option that he will face this race condition.

            Show
            vollmilch Benjamin Fuchs added a comment - - edited We are also having a problem with this issue. 1. There is a "branch" build of the "branch" job running 2. While its running a pull request is opened for that branch. 3. Multibranch scanning gets triggered. 4. The PR gets a "PR" project and a "PR" build starts running. (5. I guess the Multibranch scanning has to be triggered again.) 6. Now the "branch" project gets disabled while the "branch" job is still running. The "branch" build will now never update its status to Bitbucket. This is a major issue, since the developer cannot merge its PR due to a running job. I found out that this line is the problem when updating the status at the end of the job: https://github.com/jenkinsci/bitbucket-branch-source-plugin/blob/3412b4eb5b35b9ade7a4e6cfafcdbf3375789fcb/src/main/java/com/cloudbees/jenkins/plugins/bitbucket/BitbucketBuildStatusNotifications.java#L101 s is of type NullSCMSource and I guess it is due to the branch being removed from "sources" in: https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/MultiBranchProject.java I create a workaround for us since this was a blocker: https://github.com/benjaminfuchs/bitbucket-branch-source-plugin/tree/JENKINS-45643 If there will be now "quickfix" I guess at least the description in the job config should be updated to pointing to this issue so it is clear to a new user choosing this option that he will face this race condition.
            Hide
            thomaskeller Thomas Keller added a comment -

            This is really a blocker for the usage of this plugin. The only way to circumvent this issue is to build each PR twice, by disabling the option "exclude branches that are also filed as PRs", but this will just raise the load on the node for no reason.

            I figured if a branch pattern could be applied that would only apply to non-PR branches this could also be worked around (by including only named, important branches there), but sadly, the implemented regex / wildcard filters read NOTE: this filter will be applied to all branch like things, including change requests so this is not an option.

            Any reason why the quickfix from Benjamin Fuchs hasn't been considered yet?

            Show
            thomaskeller Thomas Keller added a comment - This is really a blocker for the usage of this plugin. The only way to circumvent this issue is to build each PR twice, by disabling the option "exclude branches that are also filed as PRs", but this will just raise the load on the node for no reason. I figured if a branch pattern could be applied that would only apply to non-PR branches this could also be worked around (by including only named, important branches there), but sadly, the implemented regex / wildcard filters read  NOTE: this filter will be applied to all branch like things, including change requests  so this is not an option. Any reason why the quickfix from Benjamin Fuchs hasn't been considered yet?
            Hide
            therealwaldo Will Freeman added a comment - - edited

            Note; this is a full on blocker for us, causing huge headaches on a daily basis.

             

            One example of the behaviour is as follows (in addition to others listed above):

            1. Build triggered, updates Bitbucket commit build status as 'build in progress', build starts
            2. Job is marked as disabled (can be because PR is merged, branch is gone, or simply that the configuration of the job has changed)
            3. Bitbucket status is frozen as 'in progress', regardless of if the job finishes.

             

            I believe this all hinges on the fact that a disabled job never fires an update if the job is disabled, regardless of the build state, and whether the PR exists/is closed, etc.

             

            Triggers are fired on change, not poll.

            You can also simulate by opening a pull request, closing it before the build finishes, then opening another PR with the exact same head, and you'll never be able to merge that PR (unless you push yet another change).

            Show
            therealwaldo Will Freeman added a comment - - edited Note; this is a full on blocker for us, causing huge headaches on a daily basis.   One example of the behaviour is as follows (in addition to others listed above): Build triggered, updates Bitbucket commit build status as 'build in progress', build starts Job is marked as disabled (can be because PR is merged, branch is gone, or simply that the configuration of the job has changed) Bitbucket status is frozen as 'in progress', regardless of if the job finishes.   I believe this all hinges on the fact that a disabled job never fires an update if the job is disabled, regardless of the build state, and whether the PR exists/is closed, etc.   Triggers are fired on change, not poll. You can also simulate by opening a pull request, closing it before the build finishes, then opening another PR with the exact same head, and you'll never be able to merge that PR (unless you push yet another change).
            Hide
            vollmilch Benjamin Fuchs added a comment - - edited

            Will Freeman Thomas Keller I just created a pull request from my workaround. We are using this already in our productiv system.

            Show
            vollmilch Benjamin Fuchs added a comment - - edited Will Freeman Thomas Keller I just created a pull request from my workaround. We are using this already in our productiv system.
            Hide
            mrkita Morgan Kita added a comment -

            This is a total blocker for our team, where we first build Feature-Branch builds without PRs and at some point create a PR, where there can be an active branch build at the time of the creation.

             

            This is definitely not a minor bug, and makes this feature unusable as is. If there is a workaround, can someone look into its mergability please?

            Show
            mrkita Morgan Kita added a comment - This is a total blocker for our team, where we first build Feature-Branch builds without PRs and at some point create a PR, where there can be an active branch build at the time of the creation.   This is definitely not a minor bug, and makes this feature unusable as is. If there is a workaround, can someone look into its mergability please?

              People

              • Assignee:
                Unassigned
                Reporter:
                casz Joseph Petersen
              • Votes:
                5 Vote for this issue
                Watchers:
                10 Start watching this issue

                Dates

                • Created:
                  Updated: