The up-to-date requirement should not be there (for the reasons you mentioned). There was a bug with the Infra asf.yaml parser, so Infra manually removed the up-to-date requirement.
If the checks all pass and the PR is approved, it should be mergeable up-to-date or not. Let me know if this isn’t the case. Prior to the PR being approved, the UI looks like it will force you to merge in trunk, but it shouldn’t. David A On Wed, Mar 5, 2025 at 21:58 Chia-Ping Tsai <chia7...@gmail.com> wrote: > hi David > > Thank you for this protection, and I fully agree that we need to avoid > exceptional merges as much as possible. > > For another, It seems we also require PRs to be up-to-date, which is good. > However, the side effect is cache misses. I recall you've done a lot of > work on improving the cache, so I'm wondering if this protection conflicts > with cache usage. > > Best, > Chia-Ping > > David Arthur <mum...@gmail.com> 於 2025年3月6日 週四 上午4:07寫道： > > > We had a hiccup today where a PR was merged due to a false positive "All > > checks have passed" message in the UI. This message was displayed because > > the labelling workflows had run and were successful. So, really the > message > > was correct -- all checks that had been run were successful. The problem > > was, our CI was not among the checks that had run. > > > > This incident pointed out a deficiency in our PR workflow. Essentially, > we > > have to remember to set the "ci-approved" label and we need to ensure > that > > the CI checks are among the "passed" status checks before merging. > > > > To remedy this, I've added a branch protection for trunk which defines a > > required status check "build / CI checks completed". This check is set > by a > > job that runs at the end of our CI workflow. This means we cannot merge a > > PR unless the CI has run. > > > > Likely this means *all extant PRs need to merge in trunk* to run this new > > "CI checks completed" job. Sorry for the noise, but I figured it was best > > to rip the bandaid off now... > > > > Thanks! > > David A > > > > P.S., I also added our release branches as protected branches, but did > not > > add any branch protections rules. This was done to prevent forced pushing > > to these branches which we honestly should have done long ago. > > > > > > > > > > > > -- > > David Arthur > > >
