Parallelize Patch Build sequence test#2203
Conversation
There was a problem hiding this comment.
Pull request overview
Adds a GitHub Actions matrix-based patch build workflow by enumerating patches and enabling applying only the first N patches during submodule refresh, allowing patch-build steps to run in parallel up to each patch.
Changes:
- Introduce a
write-patch-matrixutility to emit a JSON matrix of patches for GitHub Actions. - Add
-taketosubmodule-refreshto apply only the first N patches by staging them into a temporary directory. - Update
patch-build.ymlto generate a matrix and run builds for each “apply patches up to N” entry.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 6 comments.
| File | Description |
|---|---|
| eng/_util/cmd/write-patch-matrix/write-patch-matrix.go | New CLI that lists patches and writes a JSON matrix (stdout or $GITHUB_OUTPUT). |
| eng/_util/cmd/submodule-refresh/submodule-refresh.go | Adds -take support via temp patch dir + file copy helper. |
| .github/workflows/patch-build.yml | Switches from sequential loop to matrix-driven parallel builds. |
|
(Delete was a misclick, seems like I misinterpreted review UI.) |
Use eng/artifacts. Rely on WalkGoPatches. Explicitly don't support zero patch files.
|
Interesting. Switching to We might not actually care if this part of buildability matters, or only the "core" part of the build. For now, skipping the race build. (This was the old behavior.) |
This workflow tests that Go is buildable after applying each patch. This takes a while, and scales O(N) per patch. This creates an artificial limit to how many patch files we add.
This PR parallelizes this workflow to O(1) per patch, as long as we're able to freely reserve agents.
Addresses #2202 (comment)