Jenkins rebuild if destination branch been commited

[jeyrichman]

I use Jenkins + BitBucket to run the Unit tests for the project. To triggering to run my job "run-unit-tests" I use the BitBucket Pull Requests Builder.

Job "run-unit-tests" has workflow:

1. Merge before build
2. Bitbucket Pull request builder
3. Run Tests
4. Notification to slack

It is working perfectly if I make a single PR. For more PR's needed to Rebuild "Pending to Merge" PR's. As mentioned on "Bitbucket Pull request Builder" this procedure implement inside the plugin by clicking to option "Rebuild if destination branch changes?". But in my case this option doesn't work and if i merge some PR to master it doesn't call to Rebuild "Pending to Merge" PR's. Maybe I doing something wrong or need to carefully set up Bitbucket. Anyhow does somebody made similar pipeline, maybe exists the different way to call "Pending to Merge" PR's i.e. via Bitbucket webhook?

[CodeMonk]

Looks like rebuild if destination changes may be broken - marking this as a bug.

[CodeMonk]

Duplicate of #142

[sayresVT]

I'm not sure this is a duplicate of #142 as that seems to be related to BranchFilter functionality. I think this is a separate issue that has existed since the build status API support was added in 620a221. A quick search for references in the project to the BitbucketBuildTrigger.getCheckDestinationCommit() flag that corresponds to the "Rebuild if destination branch changes?" doesn't turn up any results.

The way this flag used to work was something like:

1. Two pull requests exist and have A (master) as their merge target, i.e. B -> A (master) and C -> A (master).
2. The plugin kicks off two new builds, one for the branch B pull request and one for the branch C pull request
3. The pull request for B is merged into master, changing the commit from A to D
4. The next time the plugin runs, it detects that the build for pull request C was last run when master was still at commit A but is now at D, so it kicks off another build for that pull request.

We were able to reintroduce this functionality in our fork by storing the destination commit in the build status description: Q-Free-OpenRoads@e7590fa. It's been working really well for us, so I just wanted to see if this solution might make sense integrating here

[CodeMonk]

I apologize - I read it as rebuild if source branch changes, not if destination branch. I'll re-open for comment(s).

[ejrgilbert]

Any updates here? I'm still seeing this behavior.

[hartzell]

I'm also seeing this, would love to help test a fix.

[hartzell]

Could this be related to the behavior I'm seeing in #222? I'd like it to build the merge commit, once, even if it's built the commit at the head of the source commit.

Seems that might be a case of gating on the source commit id rather than remembering the last merged commit between source and target.

The problem in this issue seems to be that it's not remembering the commit in the target on which the merge was built.