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 >
