git/.github/workflows, branch v2.46.2

ci: use regular action versions for linux32 job

2024-09-12T17:21:10Z

The linux32 job runs inside a docker container with a 32-bit libc, etc. This breaks any GitHub Actions scripts that are implemented in javascript, because they ship with their own 64-bit version of Node.js that's dynamically linked. They'll fail with a message like: exec /__e/node20/bin/node: no such file or directory because they can't find the runtime linker. This hasn't been a problem until recently because we special-case older, non-javascript versions of these actions for the linux32 job. But it recently became an issue when our old version of actions/upload-artifact was deprecated, causing the job to fail. We worked around that in 90f2c7240c (ci: remove 'Upload failed tests' directories' step from linux32 jobs, 2024-09-09), but it meant a loss of functionality for that job. And we may eventually run into the same deprecation problem with actions/checkout, which can't just be removed. We can solve the linking issue by installing the 64-bit libc and stdc++ packages before doing anything else. Coupled with the switch to a more recent image in the previous patch, that lets us remove the special-casing of the action scripts entirely. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

ci: use more recent linux32 image

2024-09-12T17:21:10Z

The Xenial image we're using was released more than 8 years ago. This is a problem for using some recent GitHub Actions scripts, as they require Node.js 20, and all of the binaries they ship need glibc 2.28 or later. We're not using them yet, but moving forward prepares us for a future patch which will. Xenial was actually the last official 32-bit Ubuntu release, but you can still find i386 images for more recent releases. This patch uses Focal, which was released in 2020 (and is the oldest one with glibc 2.28). There are two small downsides here: - while Xenial is pretty old, it is still in LTS support until April 2026. So there's probably some value in testing with such an old system, and we're losing that. - there are no i386 subversion packages in the Focal repository. So we won't be able to test that (OTOH, we had never tested it until the previous patch which unified the 32/64-bit dependency code). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

ci: remove 'Upload failed tests' directories' step from linux32 jobs

2024-09-09T23:00:53Z

Linux32 jobs seem to be getting: Error: This request has been automatically failed because it uses a deprecated version of `actions/upload-artifact: v1`. Learn more: https://github.blog/changelog/2024-02-13-deprecation-notice-v1-and-v2-of-the-artifact-actions/ before doing anything useful. For now, disable the step. Ever since actions/upload-artifact@v1 got disabled, mentioning the offending version of it seems to stop anything from happening. At least this should run the same build and test. See https://github.com/git/git/actions/runs/10780030750/job/29894867249 for example. Signed-off-by: Junio C Hamano

ci(win+VS): download the vcpkg artifacts using a dedicated GitHub Action

2024-08-20T15:24:28Z

The Git for Windows project provides a GitHub Action to download and cache Azure Pipelines artifacts (such as the `vcpkg` artifacts), hiding gnarly internals, and also providing some robustness against network glitches. Let's use it. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

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

2024-08-20T15:24:27Z

The main benefit: The new version uses a node.js version that is not yet deprecated. Links: - [Release notes](https://github.com/microsoft/setup-msbuild/releases) - [Changelog](https://github.com/microsoft/setup-msbuild/blob/main/building-release.md) - [Commits](https://github.com/microsoft/setup-msbuild/compare/v1...v2) This patch was originally by GitHub's Dependabot, but I cannot attribute that bot properly because it has no dedicated email address. Probably because it hasn't reached legal age yet, or something. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'jt/port-ci-whitespace-check-to-gitlab'

2024-05-15T16:52:54Z

The "whitespace check" task that was enabled for GitHub Actions CI has been ported to GitLab CI. * jt/port-ci-whitespace-check-to-gitlab: gitlab-ci: add whitespace error check ci: make the whitespace report optional ci: separate whitespace check script github-ci: fix link to whitespace error ci: pre-collapse GitLab CI sections

Merge branch 'jk/ci-test-with-jgit-fix'

2024-05-13T17:19:47Z

CI fix. * jk/ci-test-with-jgit-fix: ci: update coverity runs_on_pool reference

Merge branch 'jk/ci-macos-gcc13-fix'

2024-05-13T17:19:47Z

CI fix. * jk/ci-macos-gcc13-fix: ci: stop installing "gcc-13" for osx-gcc ci: avoid bare "gcc" for osx-gcc job ci: drop mention of BREW_INSTALL_PACKAGES variable

ci: stop installing "gcc-13" for osx-gcc

2024-05-09T16:58:08Z

Our osx-gcc job explicitly asks to install gcc-13. But since the GitHub runner image already comes with gcc-13 installed, this is mostly doing nothing (or in some cases it may install an incremental update over the runner image). But worse, it recently started causing errors like: ==> Fetching gcc@13 ==> Downloading https://ghcr.io/v2/homebrew/core/gcc/13/blobs/sha256:fb2403d97e2ce67eb441b54557cfb61980830f3ba26d4c5a1fe5ecd0c9730d1a ==> Pouring gcc@13--13.2.0.ventura.bottle.tar.gz Error: The `brew link` step did not complete successfully The formula built, but is not symlinked into /usr/local Could not symlink bin/c++-13 Target /usr/local/bin/c++-13 is a symlink belonging to gcc. You can unlink it: brew unlink gcc which cause the whole CI job to bail. I didn't track down the root cause, but I suspect it may be related to homebrew recently switching the "gcc" default to gcc-14. And it may even be fixed when a new runner image is released. But if we don't need to run brew at all, it's one less thing for us to worry about. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

ci: avoid bare "gcc" for osx-gcc job

2024-05-09T16:57:32Z

On macOS, a bare "gcc" (without a version) will invoke a wrapper for clang, not actual gcc. Even when gcc is installed via homebrew, that only provides version-specific links in /usr/local/bin (like "gcc-13"), and never a version-agnostic "gcc" wrapper. As far as I can tell, this has been the case for a long time, and this osx-gcc job has largely been doing nothing. We can point it at "gcc-13", which will pick up the homebrew-installed version. The fix here is specific to the github workflow file, as the gitlab one does not have a matching job. It's a little unfortunate that we cannot just ask for the latest version of gcc which homebrew provides, but as far as I can tell there is no easy alias (you'd have to find the highest number gcc-* in /usr/local/bin yourself). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano