Build hangs forever if PR is merged before build starts about ghprb-plugin HOT 8 CLOSED

You are right, there should be a certain number of retries before moving on. The null check is actually waiting for github to finish deciding if the pr can be merged or not.

Have you seen an instance where it hangs forever?

from ghprb-plugin.

Yes, this is happening frequently on our instance after we upgraded. You should be able to get it by triggering a build, and merging the PR while it is in the queue.

from ghprb-plugin.

Incidentally, relating to the commented out check below that: if the PR was previously mergeable and now is not, then there's a good chance that github will have removed the ref that it uses to mark the merge commit, and so things won't work. In that case, it may be best to just abort the build.

from ghprb-plugin.

I was thinking that same thing, about aborting the build, but it is possible that the build won't be relying on the merged version anyways.

I will get a patch out today that limits to one minute of waiting for github to settle. However, if you merge the PR while it is in the queue that will cause other kinds of issues. I will have it check for isMerged also for failing.

from ghprb-plugin.

Well, unfortunately we have a busy instance, so it's very common for developers to add commits or even merge or close PRs while a build is still in the queue. It would be nice if that didn't cause problems, but as it is we have workarounds for most things.

This one we can't work around, however, as it never progresses past the start of the build!

from ghprb-plugin.

I am going to punt on aborting the build, and just rely on comments to notify the user what is going on when a build fails for strange reasons

from ghprb-plugin.

It would be significantly preferable for us if the build were to abort rather than failing. Failures usually mean the build or tests failed, which means it needs attention from the developers. This sort of failure is just github and the builder getting out of sync, and can safely be ignored. So it's a pain if it's a "failure", because it means people start ignoring failures.

As a reference point, our current PR builder setup uses its first build step to check exactly what you're checking here - has the PR merge status changed, has the head commit changed? If so, we abort the build, because it's either going to fail or be uninteresting.

Since it sounds like you're considering doing that here, I'd just like to put in a vote for aborting if things look wrong!

from ghprb-plugin.

I would do that, but there are users that don't really care if the PR is open or closed, or that there is a merge sha or not. That kind of functionality belongs in an extension or config setting instead so users can decide for themselves what should happen. You are welcome to open a PR that does so, or write up another issue as an enhancement request for said functionality.

from ghprb-plugin.