Trigger UCRT64 runs upon /git-artifacts#223
Merged
Merged
Conversation
Git for Windows is gaining a UCRT64 flavor, and I want the `/git-artifacts` command (as well as the snapshot builds that cascade from a `tag-git` run) to build those bits alongside the existing x86_64, i686 and aarch64 ones. The actual build logic lives in two other repositories: build-extra learns to assemble installers, portable Gits and the like from a UCRT64 SDK (git-for-windows/build-extra#719), and the git-artifacts pipeline gains `ucrt64` as a valid `architecture` choice (git-for-windows/git-for-windows-automation#179). This helper is what dispatches those pipeline runs, so once those two pull requests are merged it needs to start asking for the fourth architecture, too. `triggerGitArtifactsRuns()` is the single place both entry points funnel through: the `/git-artifacts` slash command when a `tag-git` run already succeeded, and the automatic cascade when a `tag-git` check-run completes. Adding `ucrt64` to its architecture list therefore covers both without touching anything else. I deliberately leave the `upload-snapshot` cascade and the `/release` command at the three established architectures for now, so the UCRT64 bits are built but not yet published anywhere. A completing `git-artifacts-ucrt64` check-run does still trigger the cascade handler, because that handler matches on the `git-artifacts-` name prefix, but it only ever looks up and forwards the three standard architectures' run IDs. The extra completion is therefore harmless and, conveniently, a failing UCRT64 build will not hold back the snapshot of the other three. Assisted-by: Opus 4.8 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The previous commit taught `/git-artifacts` to build the UCRT64 flavor, but the `upload-snapshot` cascade still only ever waited for, and forwarded, the three classic architectures. The freshly built UCRT64 bits were therefore dropped on the floor: nothing waited for that run and nothing handed its ID to the snapshot upload. Now that the snapshot pipeline can pick those bits up (git-for-windows/git-for-windows-automation#181 adds an optional `git_artifacts_ucrt64_workflow_run_id` input to `upload-snapshot.yml`, downloading the UCRT64 artifacts when the input is supplied), this teaches the helper to supply it. Both places that dispatch `upload-snapshot.yml` learn about the fourth architecture: the `git-artifacts` completion cascade in `cascadingRuns()`, and the push-to-`main` path in `handlePush()`. Adding `ucrt64` to the loop that gathers the per-architecture run IDs means the upload is held back until the UCRT64 build has finished, exactly like the other three, and the gathered ID is then passed along as the new input. This deliberately stops at snapshots. The full-release path (`/release`, which drives `release-git.yml`, and the automation side's own `architectures` list in `github-release.js`) is left UCRT64-free for the time being. Because `upload-snapshot.yml` does not declare the new input until #181 lands, dispatching it with that input beforehand would be rejected, so this change must not be merged before #181. Assisted-by: Opus 4.8 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
mjcheetham
approved these changes
Jun 23, 2026
| expect(dispatchedWorkflows[0].html_url).toEqual('dispatched-workflow-git-artifacts.yml') | ||
| expect(dispatchedWorkflows[0].payload.inputs).toEqual({ | ||
| architecture: 'aarch64', | ||
| architecture: 'ucrt64', |
Member
There was a problem hiding this comment.
Is there any particular reason for the ordering of arches here?
Member
Author
There was a problem hiding this comment.
(It just so happens to be the order in which the workflow runs are mock-dispatched.)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
With the migration from MINGW64 to UCRT64 kicked off over at git-for-windows/git-sdk-64#117, we need to build these artifacts for testing.
Let's do that automatically with every cascading run that already triggers the
git-artifactsworkflow runs for the other architectures.This PR needs git-for-windows/git-for-windows-automation#181 to be merged first.