Update the versions of the GitHub Actions used in the GitHub workflows#906
Merged
dscho merged 25 commits intomicrosoft:vfs-2.54.0from Apr 30, 2026
Merged
Update the versions of the GitHub Actions used in the GitHub workflows#906dscho merged 25 commits intomicrosoft:vfs-2.54.0from
dscho merged 25 commits intomicrosoft:vfs-2.54.0from
Conversation
The v2 of `microsoft/setup-msbuild` runs on Node.js 20, which GitHub is phasing out of the Actions runners. v3 is a minimal release whose only substantive change is moving the action's runtime to Node.js 24, so that our Visual Studio build jobs keep working once Node.js 20 is removed from the runners. The risk of this bump is very low: v3 contains no functional changes to the action itself -- it merely adds `msbuild.exe` to `PATH`, with no change to command-line flags, inputs, outputs, or default tool resolution. The only precondition is a recent-enough Actions Runner, which the github.com-hosted runners already satisfy. See also: - Release notes: https://github.com/microsoft/setup-msbuild/releases - Compare: microsoft/setup-msbuild@v2...v3 Originally-authored-by: dependabot[bot] <support@github.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
`actions/upload-artifact` and `actions/download-artifact` are tightly
coupled: the upload action writes artifact archives in a format that
the download action then reads. Because of this coupling, the two
actions should always be bumped together so that the artifact format
contract between them is satisfied.
All of our `actions/upload-artifact` uses are still on v5, with one
stray v4 occurrence. Keeping them on these versions would leave the
artifact-upload steps running on Node.js 20, which GitHub is phasing
out, and would eventually cause all upload steps to fail.
Going from v5 directly to v7 folds in two release bumps:
- v6 switches the action's default runtime from Node.js 20 to
Node.js 24 (v5 had preliminary Node 24 support but still defaulted
to Node 20). This is the main motivation for bumping now: it gets
us off the deprecated runtime.
- v7 adds two opt-in features: direct (unzipped) single-file uploads
via a new `archive: false` parameter, and an internal conversion of
the action to ESM to match the updated `@actions/*` packages.
Risk analysis: we never pass `archive`, so the zip-as-usual behavior
is unchanged. We also do not `require('@actions/*')` from any calling
workflow, so the ESM migration cannot affect us. The upload steps we
care about -- tracked files/build artifacts and failing-test
directories -- keep the same inputs (`name`, `path`) and outputs, so
the diff is purely the `@vN` identifier. The main precondition is a
recent Actions Runner (>= 2.327.1), which the github.com-hosted
runners used by our CI already satisfy.
While at it, align the one remaining `@v4` occurrence with the rest
so that every `upload-artifact` step uses the same version.
See also:
- Release notes: https://github.com/actions/upload-artifact/releases
- Compare: actions/upload-artifact@v5...v7
We use `actions/download-artifact` to pass build artifacts between
the "windows-build" / "vs-build" / "windows-meson-build" jobs and
their corresponding test jobs. All callers are currently on v6;
bumping to v8 keeps this action in lockstep with the `upload-artifact`
bump above.
What v7 and v8 change:
- v7 switches the default runtime from Node.js 20 to Node.js 24 (v6
had preliminary Node 24 support but still defaulted to Node 20).
This is the main motivation: it gets us off the deprecated runtime.
- v8 makes three further changes:
* The package is converted to ESM (invisible to workflow authors).
* The action now checks the `Content-Type` header before
attempting to unzip a download, so that directly-uploaded
(unzipped) artifacts from `upload-artifact` v7 are downloaded
correctly.
* The `digest-mismatch` behaviour is changed from warn-and-
continue to a hard failure by default.
Risk analysis: defaulting hash-mismatch to a hard failure is
strictly safer than the previous warn-and-continue behaviour -- a
mismatch points to real corruption or tampering and should stop the
run. We download archives that the same workflow just uploaded, on
the same runner fleet, so false positives are not expected. Our
usage is limited to the `name` and `path` inputs, which are
unchanged between v6 and v8, so the diff is purely the `@vN`
identifier.
See also:
- Release notes: https://github.com/actions/download-artifact/releases
- Compare: actions/download-artifact@v6...v8
Originally-authored-by: dependabot[bot] <support@github.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The only use we have of `actions/github-script` is the "skip if the
commit or tree was already tested" step in `main.yml`, which checks
whether an identical tree-SHA was already built successfully. It
currently pins v8; v9 is the latest release.
What v9 changes:
- The `ACTIONS_ORCHESTRATION_ID` environment variable is now
appended to the HTTP user-agent string. This is transparent to
our script.
- A new injected `getOctokit` factory lets scripts create
additional authenticated clients in the same step without
importing `@actions/github`. We do not use it.
- Two breaking changes affect scripts that either call
`require('@actions/github')` (fails at runtime, because
`@actions/github` v9 is now ESM-only) or that shadow the
implicit `getOctokit` parameter via `const`/`let` (syntax
error). Our script does neither -- it only uses the pre-supplied
`github` REST client and `core` helpers -- so the upgrade is
safe.
Risk analysis: the step is advisory. It sets `enabled=' but skip'`
as an optimization to avoid re-running CI on a tree that was already
tested successfully. Even if the v9 upgrade broke the script, the
surrounding `try { ... } catch (e) { core.warning(e); }` block would
degrade it to a warning and CI would still run normally. In practice
the script continues to work identically on v9.
See also:
- Release notes: https://github.com/actions/github-script/releases
- Compare: actions/github-script@v8...v9
Originally-authored-by: dependabot[bot] <support@github.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Every workflow currently pins `actions/checkout` to v5, which was
introduced primarily to move to the Node.js 24 runtime. v6 is the
next release and worth picking up so we stay on a maintained version
of the action.
The one behaviorally interesting change in v6:
`persist-credentials` now stores the helper credentials under
`$RUNNER_TEMP` instead of writing them directly into the local
`.git/config`. Two implications follow:
1. In the normal case this is an unambiguous improvement -- the
token no longer lands in `.git/config`, reducing the risk of
inadvertently leaking it through workspace archiving
(`upload-artifact` snapshots, cache entries, core dumps, ...).
2. Docker container actions require an Actions Runner of at least
v2.329.0 to find the credentials in their new location. The
github.com-hosted runners our CI uses are already past that
version, so this does not affect us. Downstream users running
self-hosted runners may need to update them before adopting
this version of the action.
Risk analysis: our checkout steps either check out the default
repository (no special credential requirements) or, in the `vs-build`
job, explicitly set `repository: microsoft/vcpkg` and
`path: compat/vcbuild/vcpkg`. Neither case relies on the precise
location of the persisted credentials -- subsequent steps interact
with the API via the runner-provided `GITHUB_TOKEN` directly -- so
the v6 credential-storage change is transparent to our workflows.
The diff is purely the `@vN` identifier; there are no input or
output changes.
See also:
- Release notes: https://github.com/actions/checkout/releases
- Changelog: https://github.com/actions/checkout/blob/main/CHANGELOG.md
- Compare: actions/checkout@v5...v6
Originally-authored-by: dependabot[bot] <support@github.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In this time and age, AI is everywhere. However, it's sometimes not very easy to use. For green-field projects it works quite a bit better than for existing legacy projects. And Git's source code is _quite_ as legacy code as they come... 😁 Now, the only way how AI can be used efficiently with legacy code is by providing enough information by way of prompt context for the AI to have a chance to make any sense of the code. The structure and the architecture is, after all, not designed for AI, but rather the opposite: By virtue of having grown organically over two decades, there is no design that AI coding models would readily grasp. So here is a document that describes all kinds of aspects about this project. The idea is to help AI by providing information that it does not have ingrained in its weights. The idea is to provide information that a human prompter might take for granted, but no coding model will have been trained on specifically. Assisted-by: Claude Opus 4.5 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
…opment This adds an extensive section about resolving merge conflicts during rebases, which happens quite often in Git for Windows' day-to-day. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
…opment AGENTS.md: add upstream contribution and worktree guidance Add sections covering the GitGitGadget workflow for contributing to upstream Git, commit message conventions specific to the upstream project, how to manage patch series with dependencies (branch thickets), effective worktree usage including --update-refs for history rewrites, and techniques for analyzing merge-structured topic branches with git replay. These learnings come from a session contributing the safe.bareRepository test preparation patches via GitGitGadget. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Assisted-by: Claude Opus 4.6
…opment AGENTS.md: document rebase, staging, and log -L tricks for AI agents Add practical recipes for three workflows that are particularly useful when AI agents work with Git: Non-interactive "interactive" rebases using `sed -i 1ib` as a sequence editor to insert a `break` command, then editing the todo file directly via the path from `git rev-parse --git-path rebase-merge/git-rebase-todo`. This avoids the impossible task of driving an interactive editor from an AI agent. Scripted hunk staging via `printf '%s\n' s y q | git add -p`, which feeds predictable keystrokes to the add-patch protocol to stage individual hunks without human interaction. The `git log -L <start>,+<count>:<file>` trick for finding which commit last touched specific lines, enabling an `hg absorb`-like workflow where the agent can identify the right fixup! target surgically rather than grepping through full diffs. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Assisted-by: Claude Opus 4.6
…opment AGENTS.md: add pre-commit checklist for lint checks Bundle the existing ASCII-only, 80-column, and whitespace validation recipes into a "pre-commit checklist" block that agents should run before every commit. The individual recipes already existed in the Coding Conventions section but were presented as reference material rather than as an actionable workflow step. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Assisted-by: Claude Opus 4.6
…opment AGENTS: document learnings from split-index + fsmonitor investigation While investigating a CI failure in the `linux-TEST-vars` job caused by the interaction between the `pt/fsmonitor-linux` and `hn/git-checkout-m-with-stash` topics in `seen`, several debugging techniques proved essential and were not previously documented. The investigation required bisecting the first-parent history of `seen` while temporarily merging the fsmonitor topic at each step. This revealed that `GIT_TEST_SPLIT_INDEX=yes` corrupts the bisect machinery's own index operations unless it is unset before cleanup checkouts. It also revealed that `fprintf(stderr, ...)` instrumentation in Git's C code is swallowed by the test framework, making Trace2 the correct instrumentation approach. A key insight was that the bug appeared Linux-specific only because `linux-TEST-vars` is the sole CI job setting `GIT_TEST_SPLIT_INDEX=yes`; there is no macOS or Windows equivalent. The actual root cause (the `index.skipHash=true` + split-index interaction producing a null `base_oid` in the shared index) is platform-independent. Add four documentation sections capturing these learnings: bisecting `seen` interactions, reproducing with exact CI variables, verifying CI platform coverage before concluding platform-specificity, and using Trace2 for instrumentation inside the test framework. Assisted-by: Claude Opus 4.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
…it-for-windows#6198) AI-assisted contributions are a reality of open source in 2025 and beyond. Contributors will use AI tools, and that includes the maintainers themselves. Over recent months, I have found AI increasingly useful for the kind of menial, tedious work that does not require much creativity but is highly boring when done by hand: resolving merge conflicts during merging-rebases, chasing down CI failures across platforms, adapting downstream patches to upstream API changes. To that end, I would like to have an `AGENTS.md` file in the code base that helps any LLM to understand the context of the project. A secondary goal of this is to preemptively help outside contributors. The risk is not AI usage per se, but low-quality AI slop: contributions where the human hits "accept" without sufficient context being available to the model (and without proper review by the human, we've all been there), resulting in changes that miss conventions, break patterns, or misunderstand the project's architecture. Git's source code is about as legacy as they come, having grown organically over two decades with no design that AI coding models would readily grasp from a narrow code sample alone. This `AGENTS.md` is designed to raise the floor on AI-assisted contributions by providing enough context that even when a human contributor fails to steer carefully, the model has the information it needs to produce something reasonable. It documents the repository structure, build process, test conventions, the object model and ODB internals, debugging techniques (Trace2, instrumenting tests, bisecting failures), the merging-rebase workflow, conflict resolution patterns, coding conventions (ASCII only, 80 columns, tabs), commit message expectations, and the GitGitGadget contribution workflow. This is information that a human might take for granted, but no coding model will have been trained on specifically. Similar `AGENTS.md` files have recently been added to other repositories in the Git for Windows project: [MINGW-packages](git-for-windows/MINGW-packages#194), [git-for-windows.github.io](git-for-windows/git-for-windows.github.io#88) and [msys2-runtime](git-for-windows/msys2-runtime@1e0ff37).
This was marked as a temporary work-around in 4538ee6 (ci: work around a problem with HTTP/2 vs libcurl v8.10.0 (git-for-windows#5165), 2024-09-24), to help CI builds pass even on macOS. The faulty libcurl version has hence been replaced with plenty of fixed ones, therefore this work-around is no longer necessary. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This was a preparatory commit for the path-walk API, which has since been upstreamed into v2.54.0. During the merging-rebase, the code changes this commit introduced were already present in the new base, leaving it empty. Drop it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Over time, as upstream Git absorbs fixes and features that originated in or were carried by Git for Windows, downstream patches accumulate that are no longer needed. The steady stream of merged PRs makes this virtually inevitable. This PR collects fixup! commits to drop three such patches during the next autosquash rebase. The HTTP/2 workaround in `t5551` was a temporary fix for a libcurl v8.10.0 regression on macOS CI runners. The faulty libcurl has long been superseded by fixed versions, making it unnecessary. The `unix-socket: avoid leak when initialization fails` patch changed `return -1` to `goto fail` in `unix_stream_connect()` so cleanup would run when `unix_sockaddr_init()` failed. Upstream fixed the same leak more surgically in c5fe29f (unix-socket: fix memory leak when chdir(3p) fails, 2025-01-30) by having `unix_sockaddr_init()` call `FREE_AND_NULL(ctx->orig_dir)` before returning, making the downstream caller-side fix redundant. The `revision: create mark_trees_uninteresting_dense()` commit was a preparatory patch for the path-walk API. That API has since been upstreamed, and this commit became empty during the merging-rebase because its changes were already in the new base.
…s#6215) This PR is a companion of gitgitgadget#2103. On Windows, `maintenance_task_geometric_repack()` opens pack index files via `pack_geometry_init()` (which `mmap()`s the `.idx` files), then spawns `git repack` as a child process without setting `child.odb_to_close`. The parent's `mmap()`s prevent the child from deleting old `.idx` files. On Windows 10 builds before the POSIX delete semantics change (between Build 17134.1304 and 18363.657, see https://stackoverflow.com/a/60512798), this results in `Unlink of file '.git/objects/pack/pack-<hash>.idx' failed. Should I try again?` during fetch-triggered auto-maintenance with the geometric strategy. The fix adds the missing `child.odb_to_close = the_repository->objects` line, matching all other maintenance tasks. The first commit introduces a `GIT_TEST_LEGACY_DELETE` environment variable to simulate legacy (pre-POSIX) delete semantics on modern Windows, so the regression test can verify the fix even on Windows 11. This fixes git-for-windows#6210. Tested-by: Patryk Miś <foss@patrykmis.com>
The v1 of `git-for-windows/setup-git-for-windows-sdk` runs on Node.js 20, which GitHub is phasing out of the Actions runners. v2 moves the action to Node.js 24 so that the CI jobs relying on a Git for Windows SDK keep working once Node.js 20 is removed. The risk is very low: v2 contains no functional changes to the SDK setup itself, only the runtime upgrade. The action still provisions the same minimal SDK and exposes the same outputs. The sole precondition is a recent Actions Runner (>= 2.327.1), which the github.com-hosted runners already satisfy. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The l10n workflow uses `mshick/add-pr-comment` to post git-po-helper reports as comments on translation pull requests. It was still pinned to v2, which runs on Node.js 20. GitHub is phasing out the Node.js 20 runtime on Actions runners, so staying on v2 will eventually cause the "Create comment in pull request for report" step to fail. The sole breaking change in v3 is the switch from Node.js 20 to Node.js 24 (https://github.com/mshick/add-pr-comment/releases/tag/v3.0.0). The action's inputs and outputs are unchanged, so the upgrade is a drop-in replacement. Subsequent v3.x releases added new opt-in features (message truncation, retry with exponential backoff, file attachments, commit comment support, "delete on status") but none of them affect existing callers that do not opt in. See also: - Changelog: https://github.com/mshick/add-pr-comment/blob/main/CHANGELOG.md - Compare: mshick/add-pr-comment@v2...v3 Pointed-out-by: Christoph Grüninger <foss@grueninger.de> Assisted-by: Claude Opus 4.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This corresponds to gitgitgadget#2097.
…erver Bump actions/checkout from v5 to v6 and git-for-windows/setup-git-for-windows-sdk from v1 to v2. Both bumps are Node.js 20 to Node.js 24 runtime migrations with no functional changes to the actions themselves. checkout v6 moves persisted credentials to `` instead of `.git/config`, which does not affect this workflow since no subsequent steps rely on the credential location. The setup-sdk v2 provisions the same minimal SDK as v1. Risk: very low. The only precondition is a recent Actions Runner, which github.com-hosted runners already satisfy. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
These are the updates for Git and for Git for Windows.
Bump actions/checkout v4 to v6, actions/upload-artifact v6 to v7, actions/download-artifact v4 to v8, actions/github-script v6 to v9, and git-for-windows/setup-git-for-windows-sdk v1 to v2. All of these are Node.js runtime migrations (Node.js 20 to 24) with no changes to the actions' inputs, outputs, or behavior that affect this workflow. The checkout v6 credential-storage change (moving tokens from `.git/config` to ``) is irrelevant here because subsequent steps do not depend on the credential location. The upload-artifact v7 adds an opt-in `archive: false` parameter we do not use. The download-artifact v8 is the matching counterpart for upload-artifact v7, maintaining the artifact format contract. The github-script v9 only updates its bundled `@actions/core` dependency. Risk: very low. All bumps are runtime-only, and the github.com-hosted runners already satisfy the minimum runner version requirements. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Bump actions/checkout v4 to v6 and actions/upload-artifact v6 to v7. Both are Node.js 20 to 24 runtime migrations. checkout v6 moves persisted credentials to ``; this workflow only uses them for the initial checkout, so the new location is irrelevant. upload-artifact v7 adds an opt-in `archive: false` parameter we do not use; the SARIF upload step continues to work identically. Risk: very low. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Bump actions/checkout from v4 to v6. This is a Node.js 20 to 24 runtime migration. The only behavioral change in v6 is that persisted credentials move to ``; this workflow checks out a single repository and the credential location does not matter for subsequent steps. Risk: very low. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Bump actions/checkout v4 to v6, actions/upload-artifact v6 to v7, actions/setup-dotnet v4 to v5, and git-for-windows/setup-git-for-windows-sdk v1 to v2. The checkout, upload-artifact, and setup-sdk bumps are Node.js 20 to 24 runtime migrations with no functional changes affecting this workflow. setup-dotnet v5 likewise migrates to Node.js 24; it adds an optional `cache` input we do not use and deprecates the `source-url` input (which we also do not use). Risk: very low. The .NET SDK resolution logic is unchanged, and the github.com-hosted runners already meet the minimum runner version. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Bump actions/checkout v4 to v6, actions/upload-artifact v6 to v7, actions/download-artifact v4 to v8, and git-for-windows/setup-git-for-windows-sdk v1 to v2. All bumps are Node.js 20 to 24 runtime migrations. checkout v6 moves persisted credentials to ``, which is irrelevant here. upload-artifact v7 and download-artifact v8 are a coupled pair maintaining the artifact format contract; the new opt-in `archive: false` parameter is not used. setup-sdk v2 provisions the same minimal SDK as v1. Risk: very low. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
derrickstolee
approved these changes
Apr 29, 2026
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.
This includes gitgitgadget#2097, git-for-windows#6220 and
fixup!s for the various GitHub workflows that are specific to Microsoft Git.