Conversation
This Action is the entry point through which dozens of Git for Windows component workflows materialise a build environment, so understanding its shape (TypeScript -> tsc -> ncc -> dist/index.js, run as a Node 24 GitHub Action) and the flavor/architecture matrix it exposes is a prerequisite for almost any non-trivial change here. New contributors and AI agents alike have so far had to reverse-engineer that picture from action.yml, the workflows, and a careful read of main.ts and src/git.ts, which loses a fair amount of context: that the bundled dist/index.js is verified by CI and must be regenerated in its own commit, that the v0/v1/v2 release trains are floating branches fast-forwarded from signed tags by release-tag.yml, that the ci-artifacts fast path only kicks in for specific flavor+runner combinations, and that the project's commit-message style is the same flowing-prose convention used elsewhere in the Git for Windows ecosystem. Write that institutional knowledge down once, in an AGENTS.md that follows the same shape used by the AGENTS.md files in https://github.com/git-for-windows/git-for-windows.github.io, https://github.com/git-for-windows/7-Zip, https://github.com/git-for-windows/git-for-windows-automation, and https://github.com/git-for-windows/msys2-runtime. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The `ucrt64` axis introduced by git-for-windows/git-sdk-64#117 is materialised from the same `git-sdk-64` repository as the existing `x86_64` axis, just from a different long-lived branch (and with the UCRT64 flavour of the MSYS2 toolchain rather than MINGW64). The two variants therefore need distinct artifact names so that the on-disk output directory and the @actions/cache key do not collide on a runner that has previously materialised the other variant. Map `architecture: ucrt64` to the `git-sdk-64` repository and pick `git-sdk-ucrt64-<flavor>` as the artifact name; leave the other three architectures untouched. This is the first piece of the larger change to teach this Action about the `ucrt64` axis; subsequent commits will hook it up in `getViaGit` and `main.ts`. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
`getViaGit` currently always tells `clone()` to fetch the `main` branch of `git-sdk-*` and of `build-extra`. For the `ucrt64` axis that will need to change: the SDK clone has to target the `ucrt64` branch of `git-sdk-64`, while the `build-extra` clone still wants `main`. Plumb a `branch` parameter (default `main`) through `clone()` so the two call sites can diverge in the next commit without further refactoring noise. No behaviour change: every existing caller still ends up cloning `main`. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
For `architecture: ucrt64` the source of truth is the long-lived `ucrt64` branch of `git-sdk-64` introduced by git-for-windows/git-sdk-64#117, not `main`. Pick the branch up front and pass it to both the GitHub API lookup that resolves the tip SHA and the subsequent `clone` call, so that `getViaGit` materialises the UCRT64 variant of the SDK rather than the MINGW64 one. The `build-extra` clone remains on `main`; that repository is shared between the two variants. Side-step the `flavor === 'minimal'` workflow-runs lookup for the `ucrt64` axis. That lookup hunts for the most recent successful CI build on the branch and there are none on `ucrt64` yet (the CI artifacts pipeline has no UCRT64 counterpart). The GCC v14.1 workaround that piggy-backs on the same code path is also a MINGW64-only concern, so falling through to the plain `getBranch` lookup is the right thing for UCRT64 from the start. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The architecture-to-MSYSTEM table in `main.ts` enumerates the MINGW32/MINGW64/CLANGARM64 environments that the SDK ships today; anything else falls through to the `Invalid architecture` failure path. Add the `ucrt64 -> UCRT64` entry from the same lookup so that, once the caller has materialised the UCRT64 variant of the SDK, the rest of the Action will export `MSYSTEM=UCRT64` and prepend `/ucrt64/bin` to PATH, just like it does for the other three axes. This is a no-op without the next commit, which is the piece that actually causes `architecture: ucrt64` to reach this code path. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The `minimal` and (since Windows 11 24H2/Server 2025) `build-installers` flavours normally short-circuit through `getViaCIArtifacts`, which pulls a pre-built tarball from the `ci-artifacts` release of the matching `git-sdk-*` repository. The `ucrt64` axis has no such pre-built artifact today; the CI-artifacts pipeline on `git-sdk-64` only produces the MINGW64 variants. Pulling those for the UCRT64 axis would silently materialise the wrong toolchain on disk. Gate the fast path on `architecture !== 'ucrt64'` so that every flavour falls through to `getViaGit`, which the previous commits already taught to clone the `ucrt64` branch of `git-sdk-64` and to stamp the cache key as `git-sdk-ucrt64-<flavor>`. Only `flavor: full` is fully wired up end-to-end at this point (it goes straight through `git worktree add`); the non-`full` flavours additionally rely on `please.sh create-sdk-artifact` in `build-extra` learning to handle `--architecture=ucrt64`, which is a follow-up tracked in git-for-windows/git-sdk-64#117 (comment). Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The previous commits taught the implementation to handle `architecture: ucrt64`, but `action.yml` is what users (and the GitHub Actions tooling that renders the marketplace page and inlines the description into IDE tooltips) actually read. Extend the `architecture` input description to mention the new axis, and call out the caveat that only `flavor: full` is wired up end-to-end at this point, since `build-extra`'s `please.sh create-sdk-artifact` does not yet know about `--architecture=ucrt64` and there is no UCRT64 asset in the `ci-artifacts` release of `git-sdk-64`. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add a `getViaGit full ucrt64` companion to the existing `getViaGit full x86_64` test. The new test pins down the two behaviours that distinguish the UCRT64 variant from the MINGW64 one, both of which would silently regress to "secretly materialise the wrong toolchain" if broken: that the artifact name is `git-sdk-ucrt64-full` rather than `git-sdk-64-full` (so caches and on-disk output directories never collide with `x86_64`), and that the clone targets the `ucrt64` branch of `git-sdk-64` rather than `main`. The clone assertion goes via `spawnAndWaitForExitCode` rather than spying on `clone` itself, because internal callers of `clone()` within `git.ts` resolve the binding at module load time and the `vi.spyOn` override of the module export does not intercept them. The existing `full x86_64` test only mocks `clone` to silence side-effects, never to assert on its arguments, so the discrepancy in style is local to this one new test. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The README is the entry point most consumers of this Action see before they wire it into their workflow, so spelling out what `ucrt64` actually does (and what it does not do yet) is important even though the implementation pieces have already landed in the preceding commits. Add a paragraph after the existing `i686` note that explains the shared-repository / distinct-branch design, the resulting distinct cache key, the `MSYSTEM=UCRT64` and `/ucrt64/bin` runtime behaviour, and the fact that only `flavor: full` is end-to-end functional today. Keep the existing one-paragraph-per-line wrapping style of the README; no other text is touched. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Now that the preceding commits have actually taught the Action about the `ucrt64` axis, document it in AGENTS.md so the institutional description there matches the code. Add a row to the architecture table covering repository, MSYSTEM, mingw bin path, and current limitations, plus a follow-up paragraph that points at git-for-windows/git-sdk-64#117 and git-for-windows/git-sdk-64#117 (comment) for the larger migration context. Mention in the relationship section that `git-sdk-64` now carries the extra long-lived `ucrt64` branch and that no UCRT64 asset exists in the `ci-artifacts` release, which is why the fast path is forcibly suppressed for that axis. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The manually-triggered `test all artifact flavors` workflow is the closest thing this repository has to an end-to-end smoke test that actually downloads an SDK and runs in-place. Without an entry for the new `ucrt64` axis it would silently keep verifying only the MINGW64 and MINGW32 paths, leaving regressions on the UCRT64 path to surface only in consumer repositories. Add a single `flavor: full, architecture: ucrt64` row via `include`, because that is the only combination wired up end-to-end at this point: the subset flavors still depend on `please.sh create-sdk-artifact` in `build-extra` learning `--architecture=ucrt64` and on a UCRT64 asset appearing in the `ci-artifacts` release of `git-sdk-64`, both tracked in git-for-windows/git-sdk-64#117 (comment). The build-installer step keys off `matrix.flavor == 'build-installers'` and is therefore skipped for the new row, which is exactly what we want. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The `test` job of `build-test` is the only PR-time gate that actually runs this Action on a clean Windows runner and pokes at the result; the matrix-based smoke test in `matrix.yml` only fires on manual dispatch. So far that gate has only covered the historical default combination (`flavor: minimal`, `architecture: x86_64`), which means any regression on the new `ucrt64` axis would slip through CI and only surface in a consumer repository. Turn the job into a matrix that adds `architecture: ucrt64` next to the existing `x86_64` row, with `flavor: full` for the UCRT64 entry because that is the only flavor wired up end-to-end at this point (the subset flavors still depend on follow-up work in `build-extra` and on the `ci-artifacts` pipeline of `git-sdk-64`, tracked in git-for-windows/git-sdk-64#117 (comment)). The verification step's previously hard-coded `/mingw64/bin/gcc` becomes `$MINGW_PREFIX/bin/gcc`, with `MINGW_PREFIX` injected from the matrix so it picks up `/mingw64` for the `x86_64` row and `/ucrt64` for the `ucrt64` row. The name follows the MSYS2 ecosystem convention for the per-environment path, which is the same variable the SDK's own shell profile exports. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
rimrul
approved these changes
Jun 12, 2026
rimrul
left a comment
rimrul
left a comment
Member
There was a problem hiding this comment.
I've skipped over AGENTS.md, because I have no clue about that, but the rest looks good to me.
dscho
added a commit
that referenced
this pull request
Jun 16, 2026
…ers` flavors (#1362) Follow-up to #1361, which added the `ucrt64` axis but only for `flavor: full`. This PR extends that to the `minimal`, `makepkg-git`, and `build-installers` flavors so the `ucrt64` axis is on equal footing with the others. The Action itself doesn't need new source code for this; it just needed `please.sh create-sdk-artifact --architecture=ucrt64` to be a working invocation, which is what git-for-windows/build-extra#710 adds. So the diff here is documentation hygiene (removing the "only `full` for now" caveats) and matrix extensions (so the new combinations are exercised both on every PR and in the manual all-flavors run). The CI-artifacts fast path stays suppressed for `ucrt64` until upstream grows a UCRT64 asset; that is a separate concern.
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.
MSYS2 deprecated MINGW64 a while back; new packages no longer get accepted there, and updates of the ones we already ship have been winding down. Git for Windows therefore has to move the SDK over to UCRT64, and the kickoff for that move on
git-sdk-64itself happened in git-for-windows/git-sdk-64#117.Several Git for Windows component repositories (notably https://github.com/git-for-windows/git, https://github.com/git-for-windows/build-extra, and https://github.com/git-for-windows/MINGW-packages) materialise their CI environment by calling into this Action. Once they want to start exercising UCRT64 builds, they have to be able to ask for
architecture: ucrt64and get a UCRT64 SDK back. That is what this PR sets up.The
ucrt64axis added here lives on a dedicated long-lived branch ofgit-sdk-64, runs underMSYSTEM=UCRT64, and keeps its on-disk output directory and cache key distinct from the existingx86_64axis so the two variants can coexist on the same runner without clobbering each other. Onlyflavor: fullis wired up end-to-end at this point; the other flavors depend on follow-up work inbuild-extraand on theci-artifactspipeline ofgit-sdk-64, both of which are explicitly tracked in git-for-windows/git-sdk-64#117 (comment).The long-term plan is to "merge --theirs"
ucrt64intomainin the git-sdk-64, therefore thearchitecture: ucrt64setting is intentionally transitional (eventually it will be synonymous tox86_64).The branch starts with a fresh
AGENTS.mdwritten against the pre-UCRT64 state of the repository, and only the later commits extend that document as the actualucrt64support lands. That way each commit reads as an accurate snapshot of the tree at that point, which makes the series easier to review one commit at a time. The final commit is the conventionalnpm run build && npm run packageregeneration ofdist/index.js.