PR #1) is labeled as ready for merging, Aviator picks the head commit for your base branch (typically
main), creates a new branch (
branch A), and applies all the commits of the labeled PR as a squash commit in
branch A. Aviator will then validate the CI for this new squash commit. If a second PR (
PR #2) is labeled while the CI for the first one is still running, Aviator will now pick the latest commit from
branch Aand create a new branch (
branch B) and apply the commits of the second PR as a squash commit to
branch B. This way the CI validation can happen in parallel using a speculative commit strategy.
branch A. Likewise if the CI for PR #2 passes, it fast forwards the head of your base branch to the head of
branch B. By using this strategy, Aviator can both maintain the linear history of your PRs and also ensure that the builds pass on each commit.
branch A, and will recreate
branch Bwith only the commits of
PR #2. This way Aviator detects failures before the commits hit the base branch, ensuring that the base branch will always remain green.
parallelin the yaml configuration.
required_checkssection. You can also override separate required checks for the parallel pipeline.
Restrict who can push to matching branchesonly if you use this setting.
main) for CI execution.