Hi, On Wed, Jun 22, 2016 at 09:57:22AM -0700, Bobby Holley wrote:
> In a bit more detail, there are basically 3 ways to manage CI: > (1) The mozilla-inbound model (land possibly-untested stuff, run CI > post-commit, perform backouts and close tree as necessary) > (2) The bors/homu model (run the full suite on the precise commit that will > be merged, and only merge it when green) > (3) The relaxed bors/homu model: Run CI in parallel on pending commits. Any > mergable commits with "recent enough" green CI runs can be merged. We do > additional periodic post-merge CI runs on the master branch to spot the > occasional intra-commit bustage. This is a bit late to the discussion; but I have been wondering for a while: can't we just pipeline the final pre-commit tests? I.e. whenever a PR is approved, it is merged on top of the current auto-commit queue and tests are started, *even if tests for a previous PR are still running*. As long as tests pass on all PRs, everything can be merged without delays. (There are several options how to handle test runs finishing out of order -- but that's a detail not fundamental to the core idea.) When a test run actually does fail, the offending PR is dropped from the auto queue; those that came after it are automatically flushed and requeued. This means the worst case is lots of failing tests, in which case we would effectively degenerate to (2) -- however, failures at this stage should actually be quite rare, as most problems are already caught by the pre-approval tests. Most of the time, we should be way faster, on the same order as (3). I believe this should preserve all the important properties of (2), while avoiding the mess from post-merge failures in (3). Thoughts? -antrik- _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
