renovatebot / app-support

Discussion/support issues for the hosted Renovate App
0 stars 0 forks source link

PRs are only automerged sometimes #113

Closed ChipWolf closed 3 years ago

ChipWolf commented 3 years ago

We see some pull requests which were raised inside of the schedule today were not automerged. https://github.com/ArchitectSMP/k8s-gitops/pull/85 https://github.com/ArchitectSMP/k8s-gitops/pull/87

The log shows "mergeStateStatus = UNKNOWN", however, there is a test which is passed on each PR. Not certain how to proceed from here

rarkins commented 3 years ago

Both those PRs appear to have been automerged by now. The UNKNOWN status you saw comes directly from GitHub in the answer of the getPr query.

ChipWolf commented 3 years ago

Curious. Thanks @rarkins. My only reservation with that is; the state hasn't changed for those PRs between the scheduled window yesterday & today. Do we know more about the conditions in getPr? Could this be another caching thing?

rarkins commented 3 years ago

"mergeStateStatus = UNKNOWN" is a field directly from GitHub's API and is not computed. The only caching of PRs is per-run, which is a pretty brief time. Was the branch/commit/PR created in the same run as this status was received?

ChipWolf commented 3 years ago

The metallb PR was created in run #306356136, the MariaDB PR was automerged in the next run #306394927, there was a subsequent run where the metallb branch was updated, extrernaldns was auto merged in the following run, the metallb branch was updated in a fifth run and it was finally automerged in the sixth.

ChipWolf commented 3 years ago

The externaldns and the metallb merge occurred outside of the schedule.

rarkins commented 3 years ago

The schedule controls branch creation, not merging. And only one branch can be merged per run, because it's a prerequisite that a branch is up to date with the base branch and passing tests before it can be automerged

ChipWolf commented 3 years ago

Ohhh, so I guess if we used requireStatusChecks: null it'd allow several through in a single run? I guess a merge schedule would be useful in GitOps scenarios where changes to the branch directly reflect on the infrastructure & should only occur during certain maintenance windows.

rarkins commented 3 years ago

It would still be one automerge per run. But it could create and merge in the same run.

ChipWolf commented 3 years ago

Alright thanks for the help. I guess a potential enhancement would be scheduling of merges & allowing multiple merges to happen in a sequence in a single run if there's no merge conflict.