You do need a "stream of changes together" (to highlight that the focus is NOT the branch) because when you run the integration tests, you need to see and check things working together, not in isolation.
Let me give you a simple example:
- Change Ifoo removes a foo() method in JGit that is not used by anyone
- Change Ibar introduces a new bar() method based on the foo() method
- You verify Change Ifoo and Ibar in isolation (NOT streamlined) and they both get the Verified +1 and merged.
Verifying all individual changes in isolations won't tell you if they work together.
With the "stream of changes", you will do instead:
- Change Ifoo removes a foo() method in JGit that no one uses.
- Change Ibar introduces a new bar() method based on the foo() method.
- Change Ifoo and Ibar are put (cherry-picked or rebased) to the "validation stream" and tested together. The build breaks, and none of the two changes are validated.
The above example is very simplistic. The problem is a lot more complex than that; however, it shows that creating a "stream of changes" for validation is key when you want to integrate and validate multiple components.
There is also an issue with execution times and tradeoffs with the speed of validating incoming changes.
Running E2E tests takes a long time (hours) and is very expensive (hundreds of $ of infrastructure time): you want to limit that to ONLY those changes that:
- Have passed the normal verification process (e.g. Eclipse's CI)
- Have been reviewed and have no vetos from being approved
The two aspects depicted above represent the reason why the trigger for running the E2E tests *cannot* be applied for all open changes targeting master.
