bulldozer icon indicating copy to clipboard operation
bulldozer copied to clipboard

MaxPullRequestPollCount shall be configurable

Open DerGolfer opened this issue 6 years ago • 3 comments

Hello,

first of all I wanna thank you for this great app :)

I have one issue: It would be helpful to have MaxPullRequestPollCount in merge.go configurable via yml file.

Reason: we have a lot of pull requests and often the use case, that branches will be merged when developers are not in office anymore. It would be bad, if PR already max count when no one is in office. Then, benefit of Bulldozer would be gone ;)

Additionally, there is none more thin which I do not understand: image

You can see in screenshot, bulldozer merged automatically develop branch into feature branch 4 times in a row. After this, a merge must be dne manually (385385c), because bulldozer stopped due to max count. But after this, bulldozer tried 7 times and it worked (bulldozer also did merge into develop). Why was max count not respected here?

Thank you in advance!

Best regards, Stefan

DerGolfer avatar May 24 '19 12:05 DerGolfer

Thanks for using Bulldozer! I think there's some confusion about the purpose of theMaxPullRequestPollCount setting, so let me try to explain what it does and then we can see if it still needs to be configurable.

This setting does not control the number of pull requests Bulldozer will merge or the number of times Bulldozer will update a feature branch by merging in develop. Instead, it is the number of times Bulldozer retries the merge operation for a single pull request in the event of some specific errors:

  • If GitHub has not calculated the mergability of the pull request yet
  • If the request to the merge API fails due to a network error
  • If GitHub returns an unexpected error code, like a 500 Internal Server Error

As these are all exceptional cases, hitting the current limit of 5 should only happen if something is broken in GitHub or with the application.

For the first case, have you seen cases where pull requests you expected to merge were not merged? If so, the application logs should explain why any pull request was or was not merged.

In the second case, did you have to resolve a merge conflict when creating commit 385385c? Bulldozer can only update a feature branch if there are no conflicts to resolve. Once conflicts are resolved, I expect it to keep updating the branch until the pull request merges, which seems to be what happened here.

bluekeyes avatar May 24 '19 16:05 bluekeyes

Hi,

thanks for clarification, that retry happens for the mentioned errors. This was not clear to me.

In the meanwhile, I was not observing anymore, that bulldozer was not doing the merges as expected (y) Maybe my given use case was an exception. Unfortunately I do not have access to these logfiles in the deployed environment, but as I said, from my perspective, bulldozer is doing a really good job!

DerGolfer avatar Jun 03 '19 07:06 DerGolfer

@bluekeyes sorry to resurrect an old issue but I noticed this issue today Github had not calculated the mergability of the PR so in the logs I see

Pull request mergeability not yet known

It retries 5 times and gets the same message each time and then in the logs I see

Failed to merge pull request after 5 attempts

Is there anyway to increase the max number of retries? Maybe having an increased length of sleep between each retry Ideally I think it should retry indefinitely or at least retry an absurdly large amount of times, definitely more than 5

RoryDoherty avatar Aug 21 '24 16:08 RoryDoherty