Branches and PRs overwrite each other statuses in Bitbucket allowing code to be merged before it is fully tested #324
Comments
|
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 |
|
I'm not sure this would be a wise move. The thing is: how much
#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. |
|
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, ***@***.***> 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
<#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
<#324 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACQ62ZEAIR4BTBX6ULCZLG3SESSPDANCNFSM4OMESQUQ>
.
|
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
bump. |
|
bump. |
|
bump |
1 similar comment
|
bump |
|
Issue JENKINS-47213 |
This behaviour has change time ago (as you described later). Each branch or PR have different keys associated to the build statuses for the same commit. Issue JENKINS-45643 and JENKINS-47213 has been fixed with PR #930 |
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: Pull-Requests no longer working on BitBucket Server 7.0 #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: #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: #298
The text was updated successfully, but these errors were encountered: