| description |
|---|
Test pull requests with a predicted view of your stable branch by including all the changes in the pull requests ahead of it. |
The core concept of any merge queue solution is predictive testing. The idea here is to test your pull request against the head of your protected branch main and all the pull requests ahead of your own in the queue. \
{% embed url="https://share.vidyard.com/watch/31gaLwGNSYTn2ec2BSQjkn" %} Test your pull request with the changes ahead of it in the queue {% endembed %}
| What's Happening? | Queue |
|---|---|
| A begins testing | main <- A |
| B begins predictive testing by including the changes in A | main <- A <- B+a <- C+ba |
| C begins predictive testing by including the changes in both A and B | main <- A <- B+a <- C+ba |
| as testing completes - pull requests can merge safely | merge A, B, C |
What's the point of predictive testing?
Normally pull requests are tested against a snapshot of the head of main when the pull request is posted to your source control provider. This can mean that by the time the pull request is actually merged - the results of the automated testing are stale.
When you merge a pull request with stale results you are effectively merging in un-tested code. The changes to the protected branch since the test was run create a blind spot in your testing regimen. With predictive testing, you no longer have a blind spot because the merge queue ensures that the pull request is tested against the state of main that will exist when your pull request is merged.
No blind spots === no build breakages.