Pre-merge testing, running checks on main branch

Hi folks,

@goncharov and I were discussing how we could improve the stability of the main branch with regards to pre-merge testing.

Here’s a proposal for a design:
https://github.com/google/llvm-premerge-checks/pull/384

Please let me know what you think.

Best,
Christian

What’s the difference between this and a fast buildbot?

1 Like

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?

2 Likes

What’s the difference between this and a fast buildbot?

The main difference here is that we run the exact same config as on pre-merge testing to make sure that this config works.

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?

  1. If we can’t apply the patch, then that’s a clear case.
  2. 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.