Rollup: Rerun multiple PRs through CI that have already indirectly passed #8367
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This concludes rollup/bundle PR testing for now.
Both previous rollup/bundle tests (#8356 and #8357) have completely passed CI, but due to early verification, the flow used to generate those PRs was undeveloped, which wouldn't yield the results we're looking for.
In addition, this rollup PR was generated using a simple bash script. The only manual intervention needed was the push of the new branch, and creation of the PR.
Included PRs:
How it works
Normally, we run CI against every single PR before merging it into the master branch. Once a PR passes and is merged, it's verified that it has a proper release label, so that the patch creation process can pull in the correct changes.
What rolling-up/bundling does is that instead of testing a single PR against CI, select PRs are merged into a temporary branch (rollup in this case), and a new PR is created to put this new branch against CI. Once it passes, the rollup PR is merged, and all rolled up PRs are automatically marked as merged and closed.
The rollup PR does not need nor should not get a release version label. Instead, the same process exists, where the individial PR should have a release version label.
For an example of what this looks like after the merge process, please refer to the following fork links:
Restrictions
For now, it is suggested that only PRs that are marked as
needs; CI
and with the samerelease-version:
labels be bundled. Other combinations are possible, but this should limit the scope of any debugging efforts that might be needed.Because of the numerous types of errors that could occur with a single PR, it is also suggested that the PRs be 1) tiny, and 2) orthogonal to each other. This way, if/when a test fails, determining where the problem within a set of PRs isn't the worst excercise in the world.
Pull request type