The first thing that comes to my mind is: instead of notifying people that they broke main (which is what the other buildbots do), could we use this setup to determine a “last green” revision that the pre-merge checks can safely be applied on top of?
I like the idea of having a “last green” branch. I’d be happy to use that branch as basis for my own development work to not get my workspace messed up with some unrelated breakages.
How do we decide if a patch on Phabricator can actually be applied reasonably to that “last green” branch?
If we can’t apply the patch, then that’s a clear case.
However there are cases, where you can apply the patch, but the build result would not be useful as it depends on some other change that was added/removed earlier/later that the current last green branch…
Do I miss something or the whole thing could be simply resumed as “setup a buildbot with the same config as the pre-merge testing”? This buildbot wouldn’t be any different from any other existing buildbot as far as I understand right? (other than maybe publishing its result to a branch…)
Running git rebase origin/premerge_green should always be OK, but if the patch is already rebased on a more recent broken change it won’t help filtering out known failures.
We’d need to actually have another branch where to push “known_bad” revisions, and warn in the revision that there are known failures.