question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Branches and PRs overwrite each other statuses in Bitbucket allowing code to be merged before it is fully tested

See original GitHub issue

Your 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:open
  • Created 3 years ago
  • Reactions:6
  • Comments:5 (1 by maintainers)

github_iconTop GitHub Comments

3reactions
muppet3000commented, Sep 7, 2020

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’m not sure this would be a wise move. The thing is: how much massive is this massive duplication? Once a branch is turned into a PR, I would not expect massive changes - if there are, better to decline and start anew. The current setup allows Jenkins to delete the branch job safely - you won’t need it later. The previous setup, as you noted, would possibly generate a situation that you need to manually fix, which occurs whenever the branch job fails, reports that, and you then need to re-run it but it’s been deleted by Jenkins. As noted, removing the PR’s branch job automated deletion would fix your issue (I do agree that the online help and docs should accurately describe this behaviour though). As would also a different option like:

  • halt an ongoing branch job when the PR is created (but this is always some sort of risky approach and I’m not sure of what’s available in jenkins api)
  • change the job result reporting querying bitbucket first with a logic like if (not on branch) or (no PR from this commit exist) -> send notification

#298 https://github.com/jenkinsci/bitbucket-branch-source-plugin/issues/298 doesn’t seem to have attracted much interest, but looking at their workflow they either probably want to also build the original branch, or the original branch build is actually a small overhead compared to the PRs.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jenkinsci/bitbucket-branch-source-plugin/issues/324#issuecomment-688201579, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQ62ZEAIR4BTBX6ULCZLG3SESSPDANCNFSM4OMESQUQ .

1reaction
viceicecommented, Jun 30, 2020

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

Read more comments on GitHub >

github_iconTop Results From Across the Web

Suggest or require checks before a merge | Bitbucket Cloud
Enforce merge checks to ensure every pull request is fully vetted before it gets merged. Require another approval from reviewers, if the source...
Read more >
How to use merge checks to enforce your master branch
Merge checks in Bitbucket make it easy to ensure that every Pull Request is fully vetted before it gets merged and keep your...
Read more >
Git branch policies and settings - Azure Repos - Microsoft Learn
Policies enforce your team's code quality and change management ... If all other policies pass, the creator can complete the PR when the ......
Read more >
Merge request dependencies - GitLab Docs
Closed merge requests still prevent their dependents from being merged, because a merge request can close regardless of whether or not the planned...
Read more >
Using stacked pull requests in GitHub - LogRocket Blog
When working with stacked PRs, it's helpful to think of your branches as a similar layer of code-change organization to git commits. You...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found