git/.github/workflows, branch v2.48.2

Merge branch 'ps/ci-meson'

2024-12-23T17:32:25Z

The meson-build procedure is integrated into CI to catch and prevent bitrotting. * ps/ci-meson: ci: wire up Meson builds t: introduce compatibility options to clar-based tests t: fix out-of-tree tests for some git-p4 tests Makefile: detect missing Meson tests meson: detect missing tests at configure time t/unit-tests: rename clar-based unit tests to have a common prefix Makefile: drop -DSUPPRESS_ANNOTATED_LEAKS ci/lib: support custom output directories when creating test artifacts

Merge branch 'js/github-windows-setup-fix'

2024-12-23T17:32:15Z

Revert recent changes to the way windows environment is set up for GitHub CI. * js/github-windows-setup-fix: GitHub ci(windows): speed up initializing Git for Windows' minimal SDK again

GitHub ci(windows): speed up initializing Git for Windows' minimal SDK again

2024-12-17T20:26:26Z

It used to be the case that initializing the minimal SDK (i.e. a radically slimmed-down subset of Git for Windows' development environment intended to perform the CI builds and little else) took a bit over one minute, would then be cached, and subsequent jobs would take at most half a dozen seconds to initialize said minimal SDK. It is important that this step is fast because we have to run the test suite in parallel, in a set of matrix jobs, to offset the slowness of the shell-based test suite, and each and every job has to initialize the very same minimal SDK. While it may sound as if parallelizing the jobs might only waste the generously-provided build minutes but at least the _wallclock_ time would pass quick, in reality it matters a lot: Frequently Git for Windows' or GitGitGadget PRs get stuck waiting for quite a while before CI builds start because other PRs' builds still spend substantial amounts of time to run, blocking due to the concurrency limit being reached. Since 91839a88277 (ci: create script to set up Git for Windows SDK, 2024-10-09), the situation has worsened: every job that requires the minimal Git for Windows SDK spends roughly two-and-a-half minutes doing so. With the switch away from the GitHub Action `setup-git-for-windows-sdk`, we incurred more downsides: - It is no longer possible for said Action to fix problems independently from the Git repository, e.g. when new rules about GitHub Actions require changes in the way the minimal SDK is initialized. - The minimal SDK was installed specifically outside of the worktree so as not to clutter it nor incur an additional cost to verify that the worktree is clean. Therefore, even if it would be nice to have a shared process between GitHub and GitLab based CI builds, let's switch the GitHub-based CI back to the tried-and-tested `setup-git-for-windows-sdk` Action. This commit partially reverts 91839a88277 (ci: create script to set up Git for Windows SDK, 2024-10-09). Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ci: wire up Meson builds

2024-12-13T14:48:47Z

Wire up CI builds for both GitLab and GitHub that use the Meson build system. While the setup is mostly trivial, one gotcha is the test output directory used to be in "t/", but now it is contained in the build directory. To unify the logic across Makefile- and Meson-based builds we explicitly set up the `TEST_OUTPUT_DIRECTORY` variable so that it is the same for both build systems. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Add additional CI jobs to avoid accidental breakage

2024-11-01T14:54:18Z

In general, we'd like to make sure Git works on the LTS versions of major Linux distributions. To do that, let's add CI jobs for the oldest regular (non-extended) LTS versions of the major distributions: Ubuntu 20.04, Debian 11, and RHEL 8. Because RHEL isn't available to the public at no charge, use AlmaLinux, which is binary compatible with it. Note that Debian does not offer the language-pack packages, but suitable locale support can be installed with the locales-all package. Otherwise, use the set of installation instructions which exist and are most similar to the existing supported distros. Signed-off-by: brian m. carlson Signed-off-by: Taylor Blau

ci: create script to set up Git for Windows SDK

2024-10-09T18:33:04Z

In order to build and test Git, we have to first set up the Git for Windows SDK, which contains various required tools and libraries. The SDK is basically a clone of [1], but that repository is quite large due to all the binaries it contains. We thus use both shallow clones and sparse checkouts to speed up the setup. To handle this complexity we use a GitHub action that is hosted externally at [2]. Unfortunately, this makes it rather hard to reuse the logic for CI platforms other than GitHub Actions. After chatting with Johannes Schindelin we came to the conclusion that it would be nice if the Git for Windows SDK would regularly publish releases that one can easily download and extract, thus moving all of the complexity into that single step. Like this, all that a CI job needs to do is to fetch and extract the resulting archive. This published release comes in the form of a new "ci-artifacts" tag that gets updated regularly [3]. Implement a new script that knows how to fetch and extract that script and convert GitHub Actions to use it. [1]: https://github.com/git-for-windows/git-sdk-64/ [2]: https://github.com/git-for-windows/setup-git-for-windows-sdk/ [3]: https://github.com/git-for-windows/git-sdk-64/releases/tag/ci-artifacts/ Helped-by: Johannes Schindelin Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'jk/ci-linux32-update'

2024-09-16T22:27:08Z

CI updates * jk/ci-linux32-update: ci: add Ubuntu 16.04 job to GitLab CI ci: use regular action versions for linux32 job ci: use more recent linux32 image ci: unify ubuntu and ubuntu32 dependencies ci: drop run-docker scripts

Merge branch 'jc/ci-upload-artifact-and-linux32'

2024-09-16T22:27:08Z

CI started failing completely for linux32 jobs, as the step to upload failed test directory uses GitHub actions that is deprecated and is now disabled. Remove the step so at least we will know if the tests are passing. * jc/ci-upload-artifact-and-linux32: ci: remove 'Upload failed tests' directories' step from linux32 jobs

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