Not building when destination (master) branch is updated (e.g. master)

[janinko]

Not building when destination (master) branch is updated (e.g. master)

[janinko]

If the pull request can be merged automatically, the plugin tests the merged state.
If the pull request can't be merged automatically, there is no way how the plugin can test the merged state. But it at least try to test the source branch.

If you want to retest the pull request against updated master (and it's still automatically mergeable), you can comment with retest this please. Testing the PR automatically every time master is updated isn't wise.

[ericbmerritt]

@janinko I would be really curious to know why it isn't wise. It seems that once master changes then the previous build is no longer valid. At the very least it should remove the 'this is good to merge' not from the pull request because it may very well not be good to merge, the thing it previously tested and built is no longer valid.

It seems strange to me to force a manual ping in a situation where the system can pick the change up automatically and do the right thing.

The only thing I can think of that might be a problem is that you may end up doing a lot of rebuilds. However, if thats an issues, it should simple be an option to disable it the feature.

[janinko]

Yes, you are right. I'll make an option.

[ericbmerritt]

thanks janinko. Two questions related to that. Will you close this issue when you add this and are you planning on doing a release to the normal plugin release path any time soon? It is still at 1.2 and I think this plugin is now at 1.4

[janinko]

1. Yes I will.
2. I released version 1.5.1 9 days ago and it should be in Jenkins Update Center.

[tmbo]

@janinko whats the status of this issue? Is it fixed?

[vmpj]

@janinko I also think this is a critical issue. We just had an issue where passing PRs were merged and broke the build, because they were incompatible. Once the first PR has been merged the second one should not have had an "all good" status anymore if the target branch has changed.

@ericbmerritt have you found any other way to handle this case? Thx

[vmpj]

The work-around I'm using now is to create a separate jenkins job which merges the pull request if the build succeeds. That job is only triggered with at trigger phase like "merge it".
So instead of clicking "Merge pull request" in github, you comment "merge it".
Jenkins/ghprb will try to test the PR merged with the latest target branch and merge it if succeeds.

That way you can never merge a stale PR and break the build.

But I still think ghprb should at least remove the "all good" message if it detects that target branch has changed.

[ehberger]

Last discussion on this was quite a while ago, but this would still be very useful. Has there been any progress on this issue? We'd also like to re-test PRs when the merge target has changed.

[walliski]

👍 For this one. Although building all pull requests again when something changes in the target branch sounds dumb, it is even dumber having to trigger all builds manually when something changes -_-.

@janinko (Sorry for ping, but really would want this fixed :/ )