git/.github/workflows, branch master

l10n: bump mshick/add-pr-comment from v2 to v3

2026-04-30T09:21:55Z

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: https://github.com/mshick/add-pr-comment/compare/v2...v3 Pointed-out-by: Christoph Grüninger Assisted-by: Claude Opus 4.6 Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ci: bump git-for-windows/setup-git-for-windows-sdk from v1 to v2

2026-04-30T09:21:55Z

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 Signed-off-by: Junio C Hamano

ci: bump actions/checkout from v5 to v6

2026-04-30T09:21:55Z

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: https://github.com/actions/checkout/compare/v5...v6 Originally-authored-by: dependabot[bot] Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ci: bump actions/github-script from v8 to v9

2026-04-30T09:21:55Z

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: https://github.com/actions/github-script/compare/v8...v9 Originally-authored-by: dependabot[bot] Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ci: bump actions/{upload,download}-artifact to v7 and v8

2026-04-30T09:21:55Z

`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: https://github.com/actions/upload-artifact/compare/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: https://github.com/actions/download-artifact/compare/v6...v8 Originally-authored-by: dependabot[bot] Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ci: bump microsoft/setup-msbuild from v2 to v3

2026-04-30T09:21:55Z

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: https://github.com/microsoft/setup-msbuild/compare/v2...v3 Originally-authored-by: dependabot[bot] Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

codeql: bump actions/cache from 4 to 5

2026-04-15T21:31:40Z

Bumps [actions/cache](https://github.com/actions/cache) from 4 to 5. - [Release notes](https://github.com/actions/cache/releases) - [Changelog](https://github.com/actions/cache/blob/main/RELEASES.md) - [Commits](https://github.com/actions/cache/compare/v4...v5) updated-dependencies: - dependency-name: actions/cache dependency-version: '5' dependency-type: direct:production update-type: version-update:semver-major Originally-authored-by: dependabot[bot] Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'jc/ci-github-actions-use-checkout-v5'

2026-04-13T20:54:57Z

CI dependency updates. * jc/ci-github-actions-use-checkout-v5: CI: bump actions/checkout from 4 to 5 for rust-analysis job

CI: bump actions/checkout from 4 to 5 for rust-analysis job

2026-04-13T18:35:31Z

GitHub Actions started complaining about use of Node.js 20 and I was wondering why only one job uses actions/checkout@v4, while everybody else already uses actions/checkout@v5. It turns out that it is caused by a semantic mismerge between e75cd059 (ci: check formatting of our Rust code, 2025-10-15) that added a new use of actions/checkout@v4 that happened very close to another change 63541ed9 (build(deps): bump actions/checkout from 4 to 5, 2025-10-16) that updated all uses of actions/checkout@v4 to use vactions/checkout@v5. Update the leftover and the last use of actions/checkout@v4 to use actions/checkout@v5 to help ourselves to move away from Node.js 20. Signed-off-by: Junio C Hamano

ci: make test slicing consistent across Meson/Make

2026-02-19T18:22:31Z

In the preceding commit we have adjusted test slicing to be one-based when using the "ci/run-test-slice.sh" script. But we also have an equivalent script for Meson that is still zero-based, which is of course inconsistent. Adapt the script to be one-based, as well, and adapt the GitHub workflow accordingly. Note that GitLab doesn't yet use the script, so it does not need to be adapted. This will change in the next commit though. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano