Branches and PRs overwrite each other statuses in Bitbucket allowing code to be merged before it is fully tested
See original GitHub issueYour checklist for this issue
-
Jenkins version
-
Plugin version
-
Bitbucket cloud
-
Bitbucket server and version
Description
-
Jenkins version: 2.235.1 (The Jenkins version is irrelevant)
-
Plugin version: Any version >= 2.4.3 (we are currently using 2.8.1-rc646.71e4d09c0b37 as a result of this issue: https://github.com/jenkinsci/bitbucket-branch-source-plugin/issues/287)
-
Bitbucket server and version: Server version 7.1.1 (The Bitbucket version is irrelevant)
-
Issue: When a feature branch and a pull request branch are both running at the same time, whichever one finishes first causes the status in bitbucket to be updated, this will then be overwritten by the other job when it finishes. Therefore, failures may go undiagnosed either because they are overwritten by the second job, or be ignored because the code is merged before all branches have finished building.
TLDR
The following issue occurs when Jenkins is configured to use the discover branch strategy “Exclude branches that are also filed as PRs”
When a user pushes code to a feature branch the corresponding job is triggered in Jenkins. If the user then creates a pull request in BitBucket whilst this branch is building it will cause another build to get triggerd in Jenkins. All of this is expected behaviour.
However, the “build status” of the PR in Bitbucket only shows 1 build. It shows the status of whichever build updated it last e.g. it will show the status of the feature branch until the PR is triggered, then it wil show the status of the PR, then, when the feature branch completes (but the PR is still building) it will show the ‘completed’ status of the feature branch, despite the fact there is still a PR job running.
This behaviour means that for those of us who run extended sets of tests for PRs there is a window between the feature branch completing and the PR branch completing where the status in Bitbucket is shown as “passed”, when in reality there is still the possibility of a failure being reported by the PR job.
I have tracked this down to the following PR: https://github.com/jenkinsci/bitbucket-branch-source-plugin/pull/172 which was to address the following Jenkins ticket: https://issues.jenkins-ci.org/browse/JENKINS-45643 This was subsequently released in version 2.4.3 of this plugin and has been there ever since.
Now, having been a victim of JENKINS-45643 in the past myself (although I’ve always worked around it by either deleting the PR and triggering the feature branch manually, or hitting the Bitbucket REST API to override the status of the failed/pending job) I understand why the approach in PR-172 was taken. However, it overlooked the need for the status of the PR build to take precedence over all over branches.
This creates a difficult situation on how to proceed as we don’t want to introduce a regression to the plugin by removing this functionality. That said, the position we’re currently in is that users of the plugin are potentially being misled by the status of jobs appearing in Bitbucket.
One ‘workaround’ that I have considered is to stop using the “Exclude branches that are also filed as PRs” and just use “All branches” but that will massively duplicate the number of builds happening in Jenkins.
Proposed solution
My proposal (if it’s possible to implement) would be to add a tickbox in the configuration of the plugin (much like the recent additions of “Call Can Merge” and “Call changes api”) which would allow users of the plugin to “opt in” to using the older style of naming where feature branches and PR branches show uniquely in Bitbucket, perhaps something like “Branches and PRs use different Bitbucket identifiers”.
I believe this would also resolve this issue: https://github.com/jenkinsci/bitbucket-branch-source-plugin/issues/298
Issue Analytics
- State:
- Created 3 years ago
- Reactions:6
- Comments:5 (1 by maintainers)
Top GitHub Comments
I completely understand the concern about needing to manually override statuses. I also agree that not much should change between a feature branch and a PR, however, that’s the crux of my point, a feature branch run in Jenkins in my scenario is designed to be quickly tested/verified whereas a PR build will run a more extensive set of tests that take much longer, as such I need to ensure that the status of the PR job is the one that takes precedence.
I like your suggested logic around testing if other builds are already in progress however I’m not sure how simple that would be to implement. My original suggestion around giving an option in the plugin’s configuration to switch back to the old way of generating the build hash thus creating 2 jobs in bitbucket seems like the simplest solution that allows those of us in my situation to Opt-in to this method.
On Mon, 7 Sep 2020, 10:35 sacchettom, notifications@github.com wrote:
I would also like a predictable (configurable) identifier as we would like to add bots, which depends on specific build states to be passed before they do something