git-artifacts: add support for UCRT64#179
Merged
Merged
Conversation
Following the same pattern as the `build-and-deploy` workflow, teach `git-artifacts.yml` about the new `ucrt64` pseudo architecture so that Git for Windows release artifacts can be built for the UCRT64 environment. This adds `ucrt64` to the architecture input choices and a new case in the "Configure environment" step that maps the pseudo architecture to MSYSTEM=UCRT64, MINGW_PREFIX=/ucrt64 and the package prefix `mingw-w64-ucrt-x86_64`. The SDK_REPO_ARCH stays at `64` because UCRT64 uses the same `git-sdk-64` repository (just a different branch, which `setup-git-for-windows-sdk` handles internally). The default artifact set for ucrt64 falls out naturally from the existing conditionals: it is not i686 (so it gets installer, portable, archive), not aarch64 (so it gets mingit-busybox), and not x86_64 (so it skips nuget). The source package is also skipped, same as for i686 and aarch64, because the x86_64 build already produces it. The companion `--only-ucrt64` flag in build-extra's `please.sh` was added in git-for-windows/build-extra@please-build-mingw-w64-git-ucrt64. Assisted-by: Opus 4.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The sed regex that extracts the display version and ver file from the `existing_git_tag` input only matched final release tags like `v2.55.0.windows.1`. Release candidate tags like `v2.55.0-rc1.windows.1` were silently ignored, producing empty `display_version` and `ver` files that cascaded into `Expect a version, got 0 arguments` in the MinGit builder. Add `\(-rc[0-9]\+\)\?` to the regex so that release candidate tags are recognized. While at it, make issues like this easier to debug, by tracing the commands, and by verifying that a non-empty `ver` was produced. Assisted-by: Opus 4.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Member
Author
|
https://github.com/git-for-windows/git-for-windows-automation/actions/runs/27865606846 demonstrates that this essentially works (the installer and the executables are not code-signed, because the build ran on a branch other than |
dscho
force-pushed
the
build-and-deploy-ucrt64
branch
from
a3f0ea9 to
4d52ce7
Compare
Member
Author
|
And here is the first ever Portable Git UCRT64 screenshot: 
|
mjcheetham
approved these changes
Jun 22, 2026
pull Bot
pushed a commit
to frikke/gfw-helper-github-app
that referenced
this pull request
Jun 23, 2026
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>
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.
In git-for-windows/git-sdk-64#117, a long-running PR, the UCRT64 flavor of Git for Windows' SDK is being established. Multiple packages have already been deployed, and now, in conjuction with git-for-windows/build-extra#719, it is time to build installers.