git/ci, branch v2.46.2

ci: add Ubuntu 16.04 job to GitLab CI

2024-09-13T16:02:30Z

In the preceding commits we had to convert the linux32 job to be based on Ubuntu 20.04 instead of Ubuntu 16.04 due to a limitation in GitHub Workflows. This was the only job left that still tested against this old but supported Ubuntu version, and we have no other jobs that test with a comparatively old Linux distribution. Add a new job to GitLab CI that tests with Ubuntu 16.04 to cover the resulting test gap. GitLab doesn't modify Docker images in the same way GitHub does and thus doesn't fall prey to the same issue. There are two compatibility issues uncovered by this: - Ubuntu 16.04 does not support HTTP/2 in Apache. We thus cannot set `GIT_TEST_HTTPD=true`, which would otherwise cause us to fail when Apache fails to start. - Ubuntu 16.04 cannot use recent JGit versions as they depend on a more recent Java runtime than we have available. We thus disable installing any kind of optional dependencies that do not come from the package manager. These two restrictions are fine though, as we only really care about whether Git compiles and runs on such old distributions in the first place. Signed-off-by: Patrick Steinhardt 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: unify ubuntu and ubuntu32 dependencies

2024-09-12T17:21:10Z

The script to install dependencies has two separate entries for 32-bit and 64-bit Ubuntu systems. This increases the maintenance burden since both should need roughly the same packages. That hasn't been too bad so far because we've stayed on the same 32-bit image since 2017. Trying to move to a newer image revealed several problems with the linux32 job: - newer images complain about using "linux32 --32bit i386", due to seccomp restrictions. We can loosen these with a docker option, but I don't think running it is even doing anything. We use it only for pretending to "apt" that we're on a 32-bit machine, but inside the container image apt is already configured as a 32-bit system (even though the kernel outside the container is obviously 64-bit). Using the same apt invocation for both architectures just gets rid of this call entirely. - we set DEBIAN_FRONTEND to avoid hanging on packages that ask the user questions. This wasn't a problem on the old image, but it is on newer ones. The 64-bit stanza handles this already. As a bonus, the 64-bit stanza uses "apt -q" instead of redirecting output to /dev/null. This would have saved me a lot of debugging time trying to figure out why it was hanging. :) - the old image seems to have zlib-dev installed by default, but newer ones do not. In addition, there were probably many tests being skipped on the 32-bit build because we didn't have support packages installed (e.g., gpg). Now we'll run them. We do need to keep some parts split off just for 64-bit systems: our p4 and lfs installs reference x86_64/amd64 binaries. The downloaded jgit should work in theory, since it's just a jar file embedded in a shell script that relies on the system java. But the system java in our image is too old, so I've left it as 64-bit only for now. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

ci: drop run-docker scripts

2024-09-12T17:21:10Z

We haven't used these scripts since 4a6e4b9602 (CI: remove Travis CI support, 2021-11-23), as the GitHub Actions config has support for directly running jobs within docker containers. It's possible we might want to resurrect something like this in order to be more agnostic to the CI platform. But it's not clear exactly what it would look like. And in the meantime, it's just a maintenance burden as we make changes to CI config, and is subject to bitrot. In fact it's already broken; it references ci/install-docker-dependencies.sh, which went away in 9cdeb34b96 (ci: merge scripts which install dependencies, 2024-04-12). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

ci: update Perforce version to r23.2

2024-07-31T17:05:18Z

Update our Perforce version from r21.2 to r23.2. Note that the updated version is not the newest version. Instead, it is the last version where the way that Perforce is being distributed remains the same as in r21.2. Newer releases stopped distributing p4 and p4d executables as well as the macOS archives directly and would thus require more work. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'rj/test-sanitize-leak-log-fix'

2024-07-17T17:47:24Z

Tests that use GIT_TEST_SANITIZE_LEAK_LOG feature got their exit status inverted, which has been corrected. * rj/test-sanitize-leak-log-fix: test-lib: GIT_TEST_SANITIZE_LEAK_LOG enabled by default test-lib: fix GIT_TEST_SANITIZE_LEAK_LOG

Merge branch 'jc/where-is-bash-for-ci'

2024-07-16T18:18:57Z

Shell script clean-up. * jc/where-is-bash-for-ci: ci: unify bash calling convention

test-lib: GIT_TEST_SANITIZE_LEAK_LOG enabled by default

2024-07-11T15:37:44Z

As we currently describe in t/README, it can happen that: Some tests run "git" (or "test-tool" etc.) without properly checking the exit code, or git will invoke itself and fail to ferry the abort() exit code to the original caller. Therefore, GIT_TEST_SANITIZE_LEAK_LOG=true is needed to be set to capture all memory leaks triggered by our tests. It seems unnecessary to force users to remember this option, as forgetting it could lead to missed memory leaks. We could solve the problem by making it "true" by default, but that might suggest we think "false" makes sense, which isn't the case. Therefore, the best approach is to remove the option entirely while maintaining the capability to detect memory leaks in blind spots of our tests. Signed-off-by: Rubén Justo Signed-off-by: Junio C Hamano

ci: unify bash calling convention

2024-07-08T23:23:05Z

Under ci/ hierarchy, we run scripts under either "sh" (any Bourne compatible POSIX shell would work) or specifically "bash" (as they require features from bash, e.g., ${parameter/pattern/string} expansion). As we have the CI environment under our control, we can expect that /bin/sh will always be fine to run the scripts that only require a Bourne shell, but we may not know where "bash" is installed depending on the distro used. So let's make sure we start these scripts with either one of these: #!/bin/sh #!/usr/bin/env bash Yes, the latter has to assume that everybody installs "env" at that path and not as /bin/env or /usr/local/bin/env, but this currently is the best we could do. Signed-off-by: Junio C Hamano

Merge branch 'jc/fuzz-sans-curl'

2024-07-02T16:59:01Z

CI job to build minimum fuzzers learned to pass NO_CURL=NoThanks to the build procedure, as its build environment does not offer, or the rest of the build needs, anything cURL. * jc/fuzz-sans-curl: fuzz: minimum fuzzers environment lacks libcURL