{"thread":{"id":"62731","subject":"[PATCH 00/10] A couple of CI improvements","startedAt":"2025-01-03T14:47:06Z","lastAt":"2025-11-17T17:30:47Z","messageCount":57,"participants":["Patrick Steinhardt","Jeff King","Junio C Hamano","Christian Couder","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":10},"messages":[{"id":"509851","messageId":"20250103-b4-pks-ci-fixes-v1-0-a9bb95dff833@pks.im","threadId":"62731","inReplyTo":null,"subject":"[PATCH 00/10] A couple of CI improvements","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-03T14:46:37Z","receivedAt":"2025-01-03T14:47:06Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Hi,\n\nthis patch series addresses a couple of issues I've found while\ninvestigating flaky CI jobs. Besides two more fixes for flaky jobs it\nalso removes some stale code and simplifies the setup on GitHub Actions\nto always use containerized jobs on Linux.\n\nTest runs can be found for GitLab [1] and GitHub [2].\n\nThanks!\n\nPatrick\n\n[1]: https://gitlab.com/gitlab-org/git/-/merge_requests/277\n[2]: https://github.com/git/git/pull/1865\n\n---\nPatrick Steinhardt (10):\n t0060: fix EBUSY in MinGW when setting up runtime prefix\n t7422: fix flaky test caused by buffered stdout\n github: adapt containerized jobs to be rootless\n github: convert all Linux jobs to be containerized\n github: simplify computation of the job's distro\n gitlab-ci: remove the \"linux-old\" job\n gitlab-ci: add linux32 job testing against i386\n ci: stop special-casing for Ubuntu 16.04\n ci: use latest Ubuntu release\n ci: remove stale code for Azure Pipelines\n\n .github/workflows/main.yml | 78 ++++++++++++++++++++++-----------------------\n .gitlab-ci.yml | 19 ++++++-----\n ci/install-dependencies.sh | 6 ++--\n ci/lib.sh | 34 +++-----------------\n ci/print-test-failures.sh | 5 ---\n t/t0060-path-utils.sh | 10 +++---\n t/t7422-submodule-output.sh | 10 ++++--\n 7 files changed, 68 insertions(+), 94 deletions(-)\n\n\n---\nbase-commit: 1b4e9a5f8b5f048972c21fe8acafe0404096f694\nchange-id: 20250103-b4-pks-ci-fixes-2d0a23fb5c78\n\n"},{"id":"509852","messageId":"20250103-b4-pks-ci-fixes-v1-1-a9bb95dff833@pks.im","threadId":"62731","inReplyTo":"20250103-b4-pks-ci-fixes-v1-0-a9bb95dff833@pks.im","subject":"[PATCH 01/10] t0060: fix EBUSY in MinGW when setting up runtime prefix","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-03T14:46:38Z","receivedAt":"2025-01-03T14:47:07Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Two of our tests in t0060 verify that the runtime prefix functionality\nworks as expected by creating a separate directory hierarchy, copying\nthe Git executable in there and then creating scripts relative to that\nexecutable.\n\nThese tests fail quite regularly in GitLab CI with the following error:\n\n expecting success of 0060.218 '%(prefix)/ works':\n mkdir -p pretend/bin &&\n cp \"$GIT_EXEC_PATH\"/git$X pretend/bin/ &&\n git config yes.path \"%(prefix)/yes\" &&\n GIT_EXEC_PATH= ./pretend/bin/git config --path yes.path >actual &&\n echo \"$(pwd)/pretend/yes\" >expect &&\n test_cmp expect actual\n ++ mkdir -p pretend/bin\n ++ cp /c/GitLab-Runner/builds/gitlab-org/git/git.exe pretend/bin/\n cp: cannot create regular file 'pretend/bin/git.exe': Device or resource busy\n error: last command exited with $?=1\n not ok 218 - %(prefix)/ works\n\nSeemingly, the \"git.exe\" binary we are trying to overwrite is still\nbeing held open. It is somewhat puzzling why exactly that is: while the\npreceding test _does_ write to and execute the same path, it should have\nexited and shouldn't keep any backgrounded processes around. So it must\nbe held open by something else, either in MinGW or in Windows itself.\n\nWhile the root cause is puzzling, the workaround is trivial enough:\ninstead of writing the file twice we simply pull the common setup into a\nseparate test case so that we won't observe EBUSY in the first place.\n\nSigned-off-by: Patrick Steinhardt \n---\n t/t0060-path-utils.sh | 10 ++++++----\n 1 file changed, 6 insertions(+), 4 deletions(-)\n\ndiff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh\nindex dbb2e73bcd912ae6a804603ff54e4c609966fa5d..8545cdfab559b4e247cb2699965e637529fd930a 100755\n--- a/t/t0060-path-utils.sh\n+++ b/t/t0060-path-utils.sh\n@@ -592,17 +592,19 @@ test_lazy_prereq CAN_EXEC_IN_PWD '\n \t./git rev-parse\n '\n \n+test_expect_success !VALGRIND,RUNTIME_PREFIX,CAN_EXEC_IN_PWD 'setup runtime prefix' '\n+\tmkdir -p pretend/bin &&\n+\tcp \"$GIT_EXEC_PATH\"/git$X pretend/bin/\n+'\n+\n test_expect_success !VALGRIND,RUNTIME_PREFIX,CAN_EXEC_IN_PWD 'RUNTIME_PREFIX works' '\n-\tmkdir -p pretend/bin pretend/libexec/git-core &&\n+\tmkdir -p pretend/libexec/git-core &&\n \techo \"echo HERE\" | write_script pretend/libexec/git-core/git-here &&\n-\tcp \"$GIT_EXEC_PATH\"/git$X pretend/bin/ &&\n \tGIT_EXEC_PATH= ./pretend/bin/git here >actual &&\n \techo HERE >expect &&\n \ttest_cmp expect actual'\n \n test_expect_success !VALGRIND,RUNTIME_PREFIX,CAN_EXEC_IN_PWD '%(prefix)/ works' '\n-\tmkdir -p pretend/bin &&\n-\tcp \"$GIT_EXEC_PATH\"/git$X pretend/bin/ &&\n \tgit config yes.path \"%(prefix)/yes\" &&\n \tGIT_EXEC_PATH= ./pretend/bin/git config --path yes.path >actual &&\n \techo \"$(pwd)/pretend/yes\" >expect &&\n\n-- \n2.48.0.rc1.241.g6c04ab211c.dirty\n\n"},{"id":"509853","messageId":"20250103-b4-pks-ci-fixes-v1-2-a9bb95dff833@pks.im","threadId":"62731","inReplyTo":"20250103-b4-pks-ci-fixes-v1-0-a9bb95dff833@pks.im","subject":"[PATCH 02/10] t7422: fix flaky test caused by buffered stdout","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-03T14:46:39Z","receivedAt":"2025-01-03T14:47:08Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"One test in t7422 asserts that `git submodule status --recursive`\nproperly handles SIGPIPE. This test is flaky though and may sometimes\nnot see a SIGPIPE at all:\n\n expecting success of 7422.18 'git submodule status --recursive propagates SIGPIPE':\n { git submodule status --recursive 2>err; echo $?>status; } |\n grep -q X/S &&\n test_must_be_empty err &&\n test_match_signal 13 \"$(cat status)\"\n ++ git submodule status --recursive\n ++ grep -q X/S\n ++ echo 0\n ++ test_must_be_empty err\n ++ test 1 -ne 1\n ++ test_path_is_file err\n ++ test 1 -ne 1\n ++ test -f err\n ++ test -s err\n +++ cat status\n ++ test_match_signal 13 0\n ++ test 0 = 141\n ++ test 0 = 269\n ++ return 1\n error: last command exited with $?=1\n not ok 18 - git submodule status --recursive propagates SIGPIPE\n\nThe issue is caused by us using grep(1) to terminate the pipe on the\nfirst matching line in the recursing git-submodule(1) process. Standard\nstreams are typically buffered though, so this condition is racy and may\ncause us to terminate the pipe after git-submodule(1) has already\nexited, and in that case we wouldn't see the expected signal.\n\nFix the issue by converting standard streams to be unbuffered. I have\nonly been able to reproduce this issue a single time after running t7422\nwith `--stress` after an extended amount of time, so I cannot claim to\nbe fully certain that this fix is sufficient.\n\nSigned-off-by: Patrick Steinhardt \n---\n t/t7422-submodule-output.sh | 10 +++++++---\n 1 file changed, 7 insertions(+), 3 deletions(-)\n\ndiff --git a/t/t7422-submodule-output.sh b/t/t7422-submodule-output.sh\nindex f21e9203678b94701281d5339ae8bfe53d5de0ed..ba843c02c9c2da198578aec5716813de32960b86 100755\n--- a/t/t7422-submodule-output.sh\n+++ b/t/t7422-submodule-output.sh\n@@ -166,9 +166,13 @@ do\n \t'\n done\n \n-test_expect_success !MINGW 'git submodule status --recursive propagates SIGPIPE' '\n-\t{ git submodule status --recursive 2>err; echo $?>status; } |\n-\t\tgrep -q X/S &&\n+test_lazy_prereq STDBUF '\n+\tstdbuf --version\n+'\n+\n+test_expect_success !MINGW,STDBUF 'git submodule status --recursive propagates SIGPIPE' '\n+\t{ stdbuf -oL git submodule status --recursive 2>err; echo $?>status; } |\n+\t\tstdbuf -i0 grep -q X/S &&\n \ttest_must_be_empty err &&\n \ttest_match_signal 13 \"$(cat status)\"\n '\n\n-- \n2.48.0.rc1.241.g6c04ab211c.dirty\n\n"},{"id":"509854","messageId":"20250103-b4-pks-ci-fixes-v1-3-a9bb95dff833@pks.im","threadId":"62731","inReplyTo":"20250103-b4-pks-ci-fixes-v1-0-a9bb95dff833@pks.im","subject":"[PATCH 03/10] github: adapt containerized jobs to be rootless","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-03T14:46:40Z","receivedAt":"2025-01-03T14:47:08Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"The containerized jobs in GitHub Actions run as root, giving them\nspecial permissions to for example delete files even when the user\nshouldn't be able to due to file permissions. This limitation keeps us\nfrom using containerized jobs for most of our Ubuntu-based jobs as it\ncauses a number of tests to fail.\n\nAdapt the jobs to create a separate user that executes the test suite.\nThis follows similar infrastructure that we already have in GitLab CI.\n\nSigned-off-by: Patrick Steinhardt \n---\n .github/workflows/main.yml | 6 ++++--\n ci/install-dependencies.sh | 2 +-\n 2 files changed, 5 insertions(+), 3 deletions(-)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex 900be9957a23fcaa64e1aefd0c8638c5f84b7997..b02f5873a540b458d38e7951b4ee3d5ca598ae23 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -371,10 +371,12 @@ jobs:\n run: apt -q update && apt -q -y install libc6-amd64 lib64stdc++6\n - uses: actions/checkout@v4\n - run: ci/install-dependencies.sh\n- - run: ci/run-build-and-tests.sh\n+ - run: useradd builder --create-home\n+ - run: chown -R builder .\n+ - run: sudo --preserve-env --set-home --user=builder ci/run-build-and-tests.sh\n - name: print test failures\n if: failure() && env.FAILED_TEST_ARTIFACTS != ''\n- run: ci/print-test-failures.sh\n+ run: sudo --preserve-env --set-home --user=builder ci/print-test-failures.sh\n - name: Upload failed tests' directories\n if: failure() && env.FAILED_TEST_ARTIFACTS != ''\n uses: actions/upload-artifact@v4\ndiff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh\nindex d1cb9fa8785388b3674fcea4dd682abc0725c968..ecb5b9d36c20d3e7e96148ac628a96c62642c308 100755\n--- a/ci/install-dependencies.sh\n+++ b/ci/install-dependencies.sh\n@@ -31,7 +31,7 @@ alpine-*)\n \t;;\n fedora-*|almalinux-*)\n \tdnf -yq update >/dev/null &&\n-\tdnf -yq install make gcc findutils diffutils perl python3 gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null\n+\tdnf -yq install shadow-utils sudo make gcc findutils diffutils perl python3 gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null\n \t;;\n ubuntu-*|ubuntu32-*|debian-*)\n \t# Required so that apt doesn't wait for user input on certain packages.\n\n-- \n2.48.0.rc1.241.g6c04ab211c.dirty\n\n"},{"id":"509855","messageId":"20250103-b4-pks-ci-fixes-v1-5-a9bb95dff833@pks.im","threadId":"62731","inReplyTo":"20250103-b4-pks-ci-fixes-v1-0-a9bb95dff833@pks.im","subject":"[PATCH 05/10] github: simplify computation of the job's distro","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-03T14:46:42Z","receivedAt":"2025-01-03T14:47:09Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"We explicitly list the distro of Linux-based jobs, but it is equivalent\nto the name of the image in almost all cases, except that colons are\nreplaced with dashes. Drop the redundant information and massage it in\nour CI scripts, which is equivalent to how we do it in GitLab CI.\n\nThere are a couple of exceptions:\n\n - The \"linux32\" job, w whose distro name is different than the image\n name. This is handled by adapting all sites to use the new name.\n\n - The \"alpine\" and \"fedora\" jobs, neither of which specify a tag for\n their image. This is handled by adding the \"latest\" tag.\n\nSigned-off-by: Patrick Steinhardt \n---\n .github/workflows/main.yml | 22 ++++------------------\n ci/install-dependencies.sh | 4 ++--\n ci/lib.sh | 2 ++\n 3 files changed, 8 insertions(+), 20 deletions(-)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex 8e5847da4fab009ad699c18e1a5a336a8b45c3ed..b54da639a650682495994e3c7b137eab4e6cb3bf 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -275,7 +275,7 @@ jobs:\n CC: ${{matrix.vector.cc}}\n CC_PACKAGE: ${{matrix.vector.cc_package}}\n jobname: ${{matrix.vector.jobname}}\n- distro: ${{matrix.vector.pool}}\n+ CI_JOB_IMAGE: ${{matrix.vector.pool}}\n TEST_OUTPUT_DIRECTORY: ${{github.workspace}}/t\n runs-on: ${{matrix.vector.pool}}\n steps:\n@@ -316,63 +316,49 @@ jobs:\n - jobname: linux-sha256\n image: ubuntu:latest\n cc: clang\n- distro: ubuntu-latest\n - jobname: linux-reftable\n image: ubuntu:latest\n cc: clang\n- distro: ubuntu-latest\n - jobname: linux-gcc\n image: ubuntu:20.04\n cc: gcc\n cc_package: gcc-8\n- distro: ubuntu-20.04\n - jobname: linux-TEST-vars\n image: ubuntu:20.04\n cc: gcc\n cc_package: gcc-8\n- distro: ubuntu-20.04\n - jobname: linux-gcc-default\n image: ubuntu:latest\n cc: gcc\n- distro: ubuntu-latest\n - jobname: linux-leaks\n image: ubuntu:latest\n cc: gcc\n- distro: ubuntu-latest\n - jobname: linux-reftable-leaks\n image: ubuntu:latest\n cc: gcc\n- distro: ubuntu-latest\n - jobname: linux-asan-ubsan\n image: ubuntu:latest\n cc: clang\n- distro: ubuntu-latest\n - jobname: linux-meson\n image: ubuntu:latest\n cc: gcc\n- distro: ubuntu-latest\n - jobname: linux-musl\n- image: alpine\n- distro: alpine-latest\n+ image: alpine:latest\n # Supported until 2025-04-02.\n - jobname: linux32\n image: i386/ubuntu:focal\n- distro: ubuntu32-20.04\n - jobname: pedantic\n- image: fedora\n- distro: fedora-latest\n+ image: fedora:latest\n # A RHEL 8 compatible distro. Supported until 2029-05-31.\n - jobname: almalinux-8\n image: almalinux:8\n- distro: almalinux-8\n # Supported until 2026-08-31.\n - jobname: debian-11\n image: debian:11\n- distro: debian-11\n env:\n jobname: ${{matrix.vector.jobname}}\n- distro: ${{matrix.vector.distro}}\n CC: ${{matrix.vector.cc}}\n+ CI_JOB_IMAGE: ${{matrix.vector.image}}\n runs-on: ubuntu-latest\n container: ${{matrix.vector.image}}\n steps:\ndiff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh\nindex ecb5b9d36c20d3e7e96148ac628a96c62642c308..d5a959e25ff3236656ff3416b81732ec5c2107c1 100755\n--- a/ci/install-dependencies.sh\n+++ b/ci/install-dependencies.sh\n@@ -33,7 +33,7 @@ fedora-*|almalinux-*)\n \tdnf -yq update >/dev/null &&\n \tdnf -yq install shadow-utils sudo make gcc findutils diffutils perl python3 gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null\n \t;;\n-ubuntu-*|ubuntu32-*|debian-*)\n+ubuntu-*|i386/ubuntu-*|debian-*)\n \t# Required so that apt doesn't wait for user input on certain packages.\n \texport DEBIAN_FRONTEND=noninteractive\n \n@@ -42,7 +42,7 @@ ubuntu-*|ubuntu32-*|debian-*)\n \t\tSVN='libsvn-perl subversion'\n \t\tLANGUAGES='language-pack-is'\n \t\t;;\n-\tubuntu32-*)\n+\ti386/ubuntu-*)\n \t\tSVN=\n \t\tLANGUAGES='language-pack-is'\n \t\t;;\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex 8885ee3c3f86c62e8783d27756b8779bd491e7e6..f8b68ab8a6546802756fd516ca15a2c97223da5f 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -246,6 +246,8 @@ then\n \n \tGIT_TEST_OPTS=\"--github-workflow-markup\"\n \tJOBS=10\n+\n+\tdistro=$(echo \"$CI_JOB_IMAGE\" | tr : -)\n elif test true = \"$GITLAB_CI\"\n then\n \tCI_TYPE=gitlab-ci\n\n-- \n2.48.0.rc1.241.g6c04ab211c.dirty\n\n"},{"id":"509856","messageId":"20250103-b4-pks-ci-fixes-v1-6-a9bb95dff833@pks.im","threadId":"62731","inReplyTo":"20250103-b4-pks-ci-fixes-v1-0-a9bb95dff833@pks.im","subject":"[PATCH 06/10] gitlab-ci: remove the \"linux-old\" job","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-03T14:46:43Z","receivedAt":"2025-01-03T14:47:09Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"The \"linux-old\" job was historically testing against the oldest\nsupported LTS release of Ubuntu. But with c85bcb5de1 (gitlab-ci: switch\nfrom Ubuntu 16.04 to 20.04, 2024-10-31) it has been converted to test\nagainst Ubuntu 20.04, which already gets exercised in a couple of other\nCI jobs. It's thus not adding any significant test coverage.\n\nDrop the job.\n\nSigned-off-by: Patrick Steinhardt \n---\n .gitlab-ci.yml | 3 ---\n 1 file changed, 3 deletions(-)\n\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 9254e01583306e67dc12b6b9e0015183e1108655..00bc727865031620752771af4a9030c7de1b73df 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -36,9 +36,6 @@ test:linux:\n fi\n parallel:\n matrix:\n- - jobname: linux-old\n- image: ubuntu:20.04\n- CC: gcc\n - jobname: linux-sha256\n image: ubuntu:latest\n CC: clang\n\n-- \n2.48.0.rc1.241.g6c04ab211c.dirty\n\n"},{"id":"509857","messageId":"20250103-b4-pks-ci-fixes-v1-4-a9bb95dff833@pks.im","threadId":"62731","inReplyTo":"20250103-b4-pks-ci-fixes-v1-0-a9bb95dff833@pks.im","subject":"[PATCH 04/10] github: convert all Linux jobs to be containerized","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-03T14:46:41Z","receivedAt":"2025-01-03T14:47:09Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"We have split the CI jobs in GitHub Workflows into two categories:\n\n - Those running on a machine pool directly.\n\n - Those running in a container on the machine pool.\n\nThe latter is more flexible because it allows us to freely pick whatever\ncontainer image we want to use for a specific job, while the former only\nallows us to pick from a handful of different distros. The containerized\njobs shouldn't cause a significant slowdown, either, so they do not have\nany significant upside to the best of my knowlegde. The only upside that\nthey did have before the preceding commit is that they run as a non-root\nuser, but that has been addressed now.\n\nConvert all Linux jobs to be containerized for additional flexibility.\n\nSigned-off-by: Patrick Steinhardt \n---\n .github/workflows/main.yml | 68 ++++++++++++++++++++++++++--------------------\n 1 file changed, 39 insertions(+), 29 deletions(-)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex b02f5873a540b458d38e7951b4ee3d5ca598ae23..8e5847da4fab009ad699c18e1a5a336a8b45c3ed 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -259,20 +259,6 @@ jobs:\n fail-fast: false\n matrix:\n vector:\n- - jobname: linux-sha256\n- cc: clang\n- pool: ubuntu-latest\n- - jobname: linux-reftable\n- cc: clang\n- pool: ubuntu-latest\n- - jobname: linux-gcc\n- cc: gcc\n- cc_package: gcc-8\n- pool: ubuntu-20.04\n- - jobname: linux-TEST-vars\n- cc: gcc\n- cc_package: gcc-8\n- pool: ubuntu-20.04\n - jobname: osx-clang\n cc: clang\n pool: macos-13\n@@ -285,21 +271,6 @@ jobs:\n - jobname: osx-meson\n cc: clang\n pool: macos-13\n- - jobname: linux-gcc-default\n- cc: gcc\n- pool: ubuntu-latest\n- - jobname: linux-leaks\n- cc: gcc\n- pool: ubuntu-latest\n- - jobname: linux-reftable-leaks\n- cc: gcc\n- pool: ubuntu-latest\n- - jobname: linux-asan-ubsan\n- cc: clang\n- pool: ubuntu-latest\n- - jobname: linux-meson\n- cc: gcc\n- pool: ubuntu-latest\n env:\n CC: ${{matrix.vector.cc}}\n CC_PACKAGE: ${{matrix.vector.cc_package}}\n@@ -342,6 +313,44 @@ jobs:\n fail-fast: false\n matrix:\n vector:\n+ - jobname: linux-sha256\n+ image: ubuntu:latest\n+ cc: clang\n+ distro: ubuntu-latest\n+ - jobname: linux-reftable\n+ image: ubuntu:latest\n+ cc: clang\n+ distro: ubuntu-latest\n+ - jobname: linux-gcc\n+ image: ubuntu:20.04\n+ cc: gcc\n+ cc_package: gcc-8\n+ distro: ubuntu-20.04\n+ - jobname: linux-TEST-vars\n+ image: ubuntu:20.04\n+ cc: gcc\n+ cc_package: gcc-8\n+ distro: ubuntu-20.04\n+ - jobname: linux-gcc-default\n+ image: ubuntu:latest\n+ cc: gcc\n+ distro: ubuntu-latest\n+ - jobname: linux-leaks\n+ image: ubuntu:latest\n+ cc: gcc\n+ distro: ubuntu-latest\n+ - jobname: linux-reftable-leaks\n+ image: ubuntu:latest\n+ cc: gcc\n+ distro: ubuntu-latest\n+ - jobname: linux-asan-ubsan\n+ image: ubuntu:latest\n+ cc: clang\n+ distro: ubuntu-latest\n+ - jobname: linux-meson\n+ image: ubuntu:latest\n+ cc: gcc\n+ distro: ubuntu-latest\n - jobname: linux-musl\n image: alpine\n distro: alpine-latest\n@@ -363,6 +372,7 @@ jobs:\n env:\n jobname: ${{matrix.vector.jobname}}\n distro: ${{matrix.vector.distro}}\n+ CC: ${{matrix.vector.cc}}\n runs-on: ubuntu-latest\n container: ${{matrix.vector.image}}\n steps:\n\n-- \n2.48.0.rc1.241.g6c04ab211c.dirty\n\n"},{"id":"509858","messageId":"20250103-b4-pks-ci-fixes-v1-7-a9bb95dff833@pks.im","threadId":"62731","inReplyTo":"20250103-b4-pks-ci-fixes-v1-0-a9bb95dff833@pks.im","subject":"[PATCH 07/10] gitlab-ci: add linux32 job testing against i386","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-03T14:46:44Z","receivedAt":"2025-01-03T14:47:14Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Add another job to GitLab CI that tests against the i386 architecture.\nThis job is equivalent to the same job in GitHub Workflows.\n\nSigned-off-by: Patrick Steinhardt \n---\n .gitlab-ci.yml | 2 ++\n ci/lib.sh | 2 +-\n 2 files changed, 3 insertions(+), 1 deletion(-)\n\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 00bc727865031620752771af4a9030c7de1b73df..29e9056dd5010f8843e42aeae8410973c825de54 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -66,6 +66,8 @@ test:linux:\n image: fedora:latest\n - jobname: linux-musl\n image: alpine:latest\n+ - jobname: linux32\n+ image: i386/ubuntu:20.04\n - jobname: linux-meson\n image: ubuntu:latest\n CC: gcc\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex f8b68ab8a6546802756fd516ca15a2c97223da5f..2293849ada3b45873f80e4392ab93c65657d0f13 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -269,7 +269,7 @@ then\n \t\tCI_OS_NAME=osx\n \t\tJOBS=$(nproc)\n \t\t;;\n-\t*,alpine:*|*,fedora:*|*,ubuntu:*)\n+\t*,alpine:*|*,fedora:*|*,ubuntu:*|*,i386/ubuntu:*)\n \t\tCI_OS_NAME=linux\n \t\tJOBS=$(nproc)\n \t\t;;\n\n-- \n2.48.0.rc1.241.g6c04ab211c.dirty\n\n"},{"id":"509859","messageId":"20250103-b4-pks-ci-fixes-v1-8-a9bb95dff833@pks.im","threadId":"62731","inReplyTo":"20250103-b4-pks-ci-fixes-v1-0-a9bb95dff833@pks.im","subject":"[PATCH 08/10] ci: stop special-casing for Ubuntu 16.04","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-03T14:46:45Z","receivedAt":"2025-01-03T14:47:15Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"With c85bcb5de1 (gitlab-ci: switch from Ubuntu 16.04 to 20.04,\n2024-10-31) we have adapted the last CI job to stop using Ubuntu 16.04\nin favor of Ubuntu 20.04. Remove the special-casing we still have in our\nCI scripts.\n\nSigned-off-by: Patrick Steinhardt \n---\n ci/lib.sh | 9 +--------\n 1 file changed, 1 insertion(+), 8 deletions(-)\n\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex 2293849ada3b45873f80e4392ab93c65657d0f13..77a4aabdb8fb416c1733f02d02145b6bc0849998 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -347,14 +347,7 @@ ubuntu-*)\n \tfi\n \tMAKEFLAGS=\"$MAKEFLAGS PYTHON_PATH=/usr/bin/$PYTHON_PACKAGE\"\n \n-\tcase \"$distro\" in\n-\tubuntu-16.04)\n-\t\t# Apache is too old for HTTP/2.\n-\t\t;;\n-\t*)\n-\t\texport GIT_TEST_HTTPD=true\n-\t\t;;\n-\tesac\n+\texport GIT_TEST_HTTPD=true\n \n \t# The Linux build installs the defined dependency versions below.\n \t# The OS X build installs much more recent versions, whichever\n\n-- \n2.48.0.rc1.241.g6c04ab211c.dirty\n\n"},{"id":"509860","messageId":"20250103-b4-pks-ci-fixes-v1-9-a9bb95dff833@pks.im","threadId":"62731","inReplyTo":"20250103-b4-pks-ci-fixes-v1-0-a9bb95dff833@pks.im","subject":"[PATCH 09/10] ci: use latest Ubuntu release","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-03T14:46:46Z","receivedAt":"2025-01-03T14:47:16Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Both GitHub Actions and GitLab CI use the \"ubuntu:latest\" tag as the\ndefault image for most jobs. This tag is somewhat misleading though, as\nit does not refer to the latest release of Ubuntu, but to the latest LTS\nrelease thereof. But as we already have a couple of jobs exercising the\noldest LTS release of Ubuntu that Git still supports, it would make more\nsense to test the oldest and youngest versions of Ubuntu.\n\nAdapt these jobs to instead use the \"ubuntu:rolling\" tag, which refers\nto the actual latest release, which currently is Ubuntu 24.10.\n\nSigned-off-by: Patrick Steinhardt \n---\n .github/workflows/main.yml | 14 +++++++-------\n .gitlab-ci.yml | 14 +++++++-------\n 2 files changed, 14 insertions(+), 14 deletions(-)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex b54da639a650682495994e3c7b137eab4e6cb3bf..b90381ae015edf9db5aa4b8c0ace9bb5c549c37b 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -314,10 +314,10 @@ jobs:\n matrix:\n vector:\n - jobname: linux-sha256\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n cc: clang\n - jobname: linux-reftable\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n cc: clang\n - jobname: linux-gcc\n image: ubuntu:20.04\n@@ -328,19 +328,19 @@ jobs:\n cc: gcc\n cc_package: gcc-8\n - jobname: linux-gcc-default\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n cc: gcc\n - jobname: linux-leaks\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n cc: gcc\n - jobname: linux-reftable-leaks\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n cc: gcc\n - jobname: linux-asan-ubsan\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n cc: clang\n - jobname: linux-meson\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n cc: gcc\n - jobname: linux-musl\n image: alpine:latest\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 29e9056dd5010f8843e42aeae8410973c825de54..8ed3ff5f0373d70b6f609dc5292dda2dd7fd8f88 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -37,10 +37,10 @@ test:linux:\n parallel:\n matrix:\n - jobname: linux-sha256\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n CC: clang\n - jobname: linux-reftable\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n CC: clang\n - jobname: linux-gcc\n image: ubuntu:20.04\n@@ -51,16 +51,16 @@ test:linux:\n CC: gcc\n CC_PACKAGE: gcc-8\n - jobname: linux-gcc-default\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n CC: gcc\n - jobname: linux-leaks\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n CC: gcc\n - jobname: linux-reftable-leaks\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n CC: gcc\n - jobname: linux-asan-ubsan\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n CC: clang\n - jobname: pedantic\n image: fedora:latest\n@@ -69,7 +69,7 @@ test:linux:\n - jobname: linux32\n image: i386/ubuntu:20.04\n - jobname: linux-meson\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n CC: gcc\n artifacts:\n paths:\n\n-- \n2.48.0.rc1.241.g6c04ab211c.dirty\n\n"},{"id":"509861","messageId":"20250103-b4-pks-ci-fixes-v1-10-a9bb95dff833@pks.im","threadId":"62731","inReplyTo":"20250103-b4-pks-ci-fixes-v1-0-a9bb95dff833@pks.im","subject":"[PATCH 10/10] ci: remove stale code for Azure Pipelines","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-03T14:46:47Z","receivedAt":"2025-01-03T14:47:17Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Support for Azure Pipelines has been retired in 6081d3898f (ci: retire\nthe Azure Pipelines definition, 2020-04-11) in favor of GitHub Actions.\nOur CI library still has some infrastructure left for Azure though that\nis now unused. Remove it.\n\nSigned-off-by: Patrick Steinhardt \n---\n ci/lib.sh | 21 +--------------------\n ci/print-test-failures.sh | 5 -----\n 2 files changed, 1 insertion(+), 25 deletions(-)\n\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex 77a4aabdb8fb416c1733f02d02145b6bc0849998..4003354f16c048b969c0bb4340d2ee2777767300 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -206,26 +206,7 @@ export TERM=${TERM:-dumb}\n # Clear MAKEFLAGS that may come from the outside world.\n export MAKEFLAGS=\n \n-if test -n \"$SYSTEM_COLLECTIONURI\" || test -n \"$SYSTEM_TASKDEFINITIONSURI\"\n-then\n-\tCI_TYPE=azure-pipelines\n-\t# We are running in Azure Pipelines\n-\tCI_BRANCH=\"$BUILD_SOURCEBRANCH\"\n-\tCI_COMMIT=\"$BUILD_SOURCEVERSION\"\n-\tCI_JOB_ID=\"$BUILD_BUILDID\"\n-\tCI_JOB_NUMBER=\"$BUILD_BUILDNUMBER\"\n-\tCI_OS_NAME=\"$(echo \"$AGENT_OS\" | tr A-Z a-z)\"\n-\ttest darwin != \"$CI_OS_NAME\" || CI_OS_NAME=osx\n-\tCI_REPO_SLUG=\"$(expr \"$BUILD_REPOSITORY_URI\" : '.*/\\([^/]*/[^/]*\\)$')\"\n-\tCC=\"${CC:-gcc}\"\n-\n-\t# use a subdirectory of the cache dir (because the file share is shared\n-\t# among *all* phases)\n-\tcache_dir=\"$HOME/test-cache/$SYSTEM_PHASENAME\"\n-\n-\tGIT_TEST_OPTS=\"--write-junit-xml\"\n-\tJOBS=10\n-elif test true = \"$GITHUB_ACTIONS\"\n+if test true = \"$GITHUB_ACTIONS\"\n then\n \tCI_TYPE=github-actions\n \tCI_BRANCH=\"$GITHUB_REF\"\ndiff --git a/ci/print-test-failures.sh b/ci/print-test-failures.sh\nindex 655687dd827e5b3e4d4879803b0d4499e7751380..dc910e51609cd7344b1ad03fdb4e820e47ad3a88 100755\n--- a/ci/print-test-failures.sh\n+++ b/ci/print-test-failures.sh\n@@ -39,11 +39,6 @@ do\n \t\ttest_name=\"${test_name##*/}\"\n \t\ttrash_dir=\"trash directory.$test_name\"\n \t\tcase \"$CI_TYPE\" in\n-\t\tazure-pipelines)\n-\t\t\tmkdir -p failed-test-artifacts\n-\t\t\tmv \"$trash_dir\" failed-test-artifacts\n-\t\t\tcontinue\n-\t\t\t;;\n \t\tgithub-actions)\n \t\t\tmkdir -p failed-test-artifacts\n \t\t\techo \"FAILED_TEST_ARTIFACTS=${TEST_OUTPUT_DIRECTORY:t}/failed-test-artifacts\" >>$GITHUB_ENV\n\n-- \n2.48.0.rc1.241.g6c04ab211c.dirty\n\n"},{"id":"509874","messageId":"20250103181739.GA2527684@coredump.intra.peff.net","threadId":"62731","inReplyTo":"20250103-b4-pks-ci-fixes-v1-2-a9bb95dff833@pks.im","subject":"Re: [PATCH 02/10] t7422: fix flaky test caused by buffered stdout","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-01-03T18:17:39Z","receivedAt":"2025-01-03T18:17:43Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 03, 2025 at 03:46:39PM +0100, Patrick Steinhardt wrote:\n\n> One test in t7422 asserts that `git submodule status --recursive`\n> properly handles SIGPIPE. This test is flaky though and may sometimes\n> not see a SIGPIPE at all:\n> \n> expecting success of 7422.18 'git submodule status --recursive propagates SIGPIPE':\n> { git submodule status --recursive 2>err; echo $?>status; } |\n> grep -q X/S &&\n> test_must_be_empty err &&\n> test_match_signal 13 \"$(cat status)\"\n\nI couldn't reproduce with --stress, but you can trigger it all the time\nwith:\n\ndiff --git a/t/t7422-submodule-output.sh b/t/t7422-submodule-output.sh\nindex f21e920367..9338c75626 100755\n--- a/t/t7422-submodule-output.sh\n+++ b/t/t7422-submodule-output.sh\n@@ -168,7 +168,7 @@ done\n \n test_expect_success !MINGW 'git submodule status --recursive propagates SIGPIPE' '\n \t{ git submodule status --recursive 2>err; echo $?>status; } |\n-\t\tgrep -q X/S &&\n+\t\t{ sleep 1 && grep -q X/S; } &&\n \ttest_must_be_empty err &&\n \ttest_match_signal 13 \"$(cat status)\"\n '\n\nThe problem is that git-submodule may write all of its output before\ngrep exits, and it gets stored in the pipe buffer. And then even if grep\nexits before reading all of it, it is too late for SIGPIPE, and the data\nin the pipe is just discarded by the OS.\n\nSo this:\n\n> The issue is caused by us using grep(1) to terminate the pipe on the\n> first matching line in the recursing git-submodule(1) process. Standard\n> streams are typically buffered though, so this condition is racy and may\n> cause us to terminate the pipe after git-submodule(1) has already\n> exited, and in that case we wouldn't see the expected signal.\n> \n> Fix the issue by converting standard streams to be unbuffered. I have\n> only been able to reproduce this issue a single time after running t7422\n> with `--stress` after an extended amount of time, so I cannot claim to\n> be fully certain that this fix is sufficient.\n\nisn't quite right. Even without input buffering on grep's part, it may\nbe too slow to read the data. And adding a sleep as above shows that it\nstill fails with your patch.\n\nThe usual way to reliably get SIGPIPE is to make sure the writer\nproduces enough data to fill the pipe buffer. But it's tricky to get\n\"submodule status\" to produce a lot of data without having a ton of\nsubmodules, which is expensive to set up.\n\nBut we can hack around it by stuffing the pipe full with a separate\nprocess. Like this:\n\ndiff --git a/t/t7422-submodule-output.sh b/t/t7422-submodule-output.sh\nindex f21e920367..c4df2629e8 100755\n--- a/t/t7422-submodule-output.sh\n+++ b/t/t7422-submodule-output.sh\n@@ -167,8 +167,15 @@ do\n done\n \n test_expect_success !MINGW 'git submodule status --recursive propagates SIGPIPE' '\n-\t{ git submodule status --recursive 2>err; echo $?>status; } |\n-\t\tgrep -q X/S &&\n+\t{\n+\t\t# stuff pipe buffer full of input so that submodule status\n+\t\t# will require blocking on write; this script will write over\n+\t\t# 128kb. It might itself get SIGPIPE, so we must not &&-chain\n+\t\t# it directly.\n+\t\t{ perl -le \"print q{foo} for (1..33000)\" || true; } &&\n+\t\tgit submodule status --recursive 2>err\n+\t\techo $? >status\n+\t} | { sleep 1 && head -n 1 >/dev/null; } &&\n \ttest_must_be_empty err &&\n \ttest_match_signal 13 \"$(cat status)\"\n '\nA few notes:\n\n - the sleep is still there to demonstrate that it always works, but\n obviously we'd want to remove that\n\n - I swapped out \"grep\" for \"head\". What we are matching is not\n relevant; the important thing is that the reader closes the pipe\n immediately. So I guess in that sense we could probably even just\n pipe to \"true\" or similar.\n\n - I tried using test_seq to avoid the inline perl, but it doesn't\n work! The problem is that it's implemented as a shell function. So\n when it gets SIGPIPE, the whole subshell is killed, and we never\n even run git-submodule at all. So it has to be a separate process\n (though I guess it could be test_seq in a subshell).\n\nAnyway, hopefully that gives you enough to play around with.\n\n-Peff\n"},{"id":"509876","messageId":"20250103185640.GA3208749@coredump.intra.peff.net","threadId":"62731","inReplyTo":"20250103-b4-pks-ci-fixes-v1-4-a9bb95dff833@pks.im","subject":"Re: [PATCH 04/10] github: convert all Linux jobs to be containerized","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-01-03T18:56:40Z","receivedAt":"2025-01-03T18:56:42Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 03, 2025 at 03:46:41PM +0100, Patrick Steinhardt wrote:\n\n> We have split the CI jobs in GitHub Workflows into two categories:\n> \n> - Those running on a machine pool directly.\n> \n> - Those running in a container on the machine pool.\n> \n> The latter is more flexible because it allows us to freely pick whatever\n> container image we want to use for a specific job, while the former only\n> allows us to pick from a handful of different distros. The containerized\n> jobs shouldn't cause a significant slowdown, either, so they do not have\n> any significant upside to the best of my knowlegde. The only upside that\n> they did have before the preceding commit is that they run as a non-root\n> user, but that has been addressed now.\n\nI remember running into a few issues recently with containerized jobs,\nso I dug in the archive a bit. The issue there was that the container\nwas not equipped to support the dynamically-linked version of node that\nwas being mounted into place (whereas the runner image from the CI\nprovider would work fine).\n\nI guess that's probably not a big deal for us here. These are roughly\nthe same environments, just pulling from docker instead of relying on\nthe runner images. It's possible that Actions scripts might depend on\nsomething special in the runner image, but in practice I think they try\nto keep the dependencies pretty light.\n\nSo we're probably OK to proceed here, and deal with any problems in the\nunlikely event that they come up.\n\nI do wonder if it will affect run times. Presumably GitHub has made it\npretty fast to get things started on the bare runner image. Now we're\npulling docker images. That is hopefully pretty optimized and cached,\nbut it is extra work. Might be worth measuring.\n\n-Peff\n"},{"id":"509877","messageId":"20250103185727.GB3208749@coredump.intra.peff.net","threadId":"62731","inReplyTo":"20250103-b4-pks-ci-fixes-v1-0-a9bb95dff833@pks.im","subject":"Re: [PATCH 00/10] A couple of CI improvements","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-01-03T18:57:27Z","receivedAt":"2025-01-03T18:57:28Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 03, 2025 at 03:46:37PM +0100, Patrick Steinhardt wrote:\n\n> this patch series addresses a couple of issues I've found while\n> investigating flaky CI jobs. Besides two more fixes for flaky jobs it\n> also removes some stale code and simplifies the setup on GitHub Actions\n> to always use containerized jobs on Linux.\n\nI left comments on two patches, but the rest seemed fine to me (and I am\nvery happy to see cleanup of old/stale code).\n\n-Peff\n"},{"id":"509879","messageId":"20250103190659.GC3208749@coredump.intra.peff.net","threadId":"62731","inReplyTo":"20250103185640.GA3208749@coredump.intra.peff.net","subject":"Re: [PATCH 04/10] github: convert all Linux jobs to be containerized","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-01-03T19:06:59Z","receivedAt":"2025-01-03T19:07:07Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 03, 2025 at 01:56:40PM -0500, Jeff King wrote:\n\n> I do wonder if it will affect run times. Presumably GitHub has made it\n> pretty fast to get things started on the bare runner image. Now we're\n> pulling docker images. That is hopefully pretty optimized and cached,\n> but it is extra work. Might be worth measuring.\n\nJust peeking at your CI run here:\n\n https://github.com/git/git/actions/runs/12597967146\n\nversus the latest run on Junio's master:\n\n https://github.com/git/git/actions/runs/12589300693\n\nI see:\n\n job | old | new\n --------------------|------|------\n linux-TEST-vars 11m30s 10m54s\n linux-asan-ubsan 30m26s 31m14s\n linux-gcc 9m47s 10m6s\n linux-gcc-default 9m47s 9m41s\n linux-leaks 25m50s 25m21s\n linux-meson 10m36s 10m41s\n linux-reftable 10m25s 10m23s\n linux-reftable-leaks 27m18s 27m28s\n linux-sha256 9m54s 10m31s\n\nSo it looks like any change is lost in the noise (sha256 is noticeably\nslower, but most jobs aren't, and some are even faster).\n\n-Peff\n"},{"id":"509881","messageId":"xmqq7c7br9xt.fsf@gitster.g","threadId":"62731","inReplyTo":"20250103-b4-pks-ci-fixes-v1-5-a9bb95dff833@pks.im","subject":"Re: [PATCH 05/10] github: simplify computation of the job's distro","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-03T19:09:34Z","receivedAt":"2025-01-03T19:09:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt writes:\n\n> We explicitly list the distro of Linux-based jobs, but it is equivalent\n> to the name of the image in almost all cases, except that colons are\n> replaced with dashes. Drop the redundant information and massage it in\n> our CI scripts, which is equivalent to how we do it in GitLab CI.\n>\n> There are a couple of exceptions:\n>\n> - The \"linux32\" job, w whose distro name is different than the image\n> name. This is handled by adapting all sites to use the new name.\n\n\"w whose\"???\n"},{"id":"509883","messageId":"xmqq34hzr9sr.fsf@gitster.g","threadId":"62731","inReplyTo":"20250103-b4-pks-ci-fixes-v1-6-a9bb95dff833@pks.im","subject":"Re: [PATCH 06/10] gitlab-ci: remove the \"linux-old\" job","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-03T19:12:36Z","receivedAt":"2025-01-03T19:12:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt writes:\n\n> The \"linux-old\" job was historically testing against the oldest\n> supported LTS release of Ubuntu. But with c85bcb5de1 (gitlab-ci: switch\n> from Ubuntu 16.04 to 20.04, 2024-10-31) it has been converted to test\n> against Ubuntu 20.04, which already gets exercised in a couple of other\n> CI jobs. It's thus not adding any significant test coverage.\n>\n> Drop the job.\n\nDropping and reducing is always welcomed ;-)\n"},{"id":"509884","messageId":"xmqqwmfbpv1x.fsf@gitster.g","threadId":"62731","inReplyTo":"20250103-b4-pks-ci-fixes-v1-4-a9bb95dff833@pks.im","subject":"Re: [PATCH 04/10] github: convert all Linux jobs to be containerized","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-03T19:16:26Z","receivedAt":"2025-01-03T19:16:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt writes:\n\n> ... The containerized\n> jobs shouldn't cause a significant slowdown, either, so they do not have\n> any significant upside to the best of my knowlegde.\n\n\"shouldn't\" is a somewhat hand-wavy word.\n\n\"knowlegde\" -> \"knowledge\".\n\nAre there security implications for us to worry about? How tightly\nare these container images controlled, relative to the way forges\nprepare their selected environments?\n\nThanks.\n"},{"id":"509973","messageId":"Z3u6kvJNlFB7obry@pks.im","threadId":"62731","inReplyTo":"20250103190659.GC3208749@coredump.intra.peff.net","subject":"Re: [PATCH 04/10] github: convert all Linux jobs to be containerized","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-06T11:12:18Z","receivedAt":"2025-01-06T11:12:22Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Fri, Jan 03, 2025 at 02:06:59PM -0500, Jeff King wrote:\n> On Fri, Jan 03, 2025 at 01:56:40PM -0500, Jeff King wrote:\n> \n> > I do wonder if it will affect run times. Presumably GitHub has made it\n> > pretty fast to get things started on the bare runner image. Now we're\n> > pulling docker images. That is hopefully pretty optimized and cached,\n> > but it is extra work. Might be worth measuring.\n> \n> Just peeking at your CI run here:\n> \n> https://github.com/git/git/actions/runs/12597967146\n> \n> versus the latest run on Junio's master:\n> \n> https://github.com/git/git/actions/runs/12589300693\n> \n> I see:\n> \n> job | old | new\n> --------------------|------|------\n> linux-TEST-vars 11m30s 10m54s\n> linux-asan-ubsan 30m26s 31m14s\n> linux-gcc 9m47s 10m6s\n> linux-gcc-default 9m47s 9m41s\n> linux-leaks 25m50s 25m21s\n> linux-meson 10m36s 10m41s\n> linux-reftable 10m25s 10m23s\n> linux-reftable-leaks 27m18s 27m28s\n> linux-sha256 9m54s 10m31s\n> \n> So it looks like any change is lost in the noise (sha256 is noticeably\n> slower, but most jobs aren't, and some are even faster).\n\nThanks for verifying my claims!\n\nPatrick\n"},{"id":"509974","messageId":"Z3u6lj_bpM7N93Fd@pks.im","threadId":"62731","inReplyTo":"20250103181739.GA2527684@coredump.intra.peff.net","subject":"Re: [PATCH 02/10] t7422: fix flaky test caused by buffered stdout","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-06T11:12:22Z","receivedAt":"2025-01-06T11:12:25Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Fri, Jan 03, 2025 at 01:17:39PM -0500, Jeff King wrote:\n> On Fri, Jan 03, 2025 at 03:46:39PM +0100, Patrick Steinhardt wrote:\n> > One test in t7422 asserts that `git submodule status --recursive`\n> > properly handles SIGPIPE. This test is flaky though and may sometimes\n> > not see a SIGPIPE at all:\n> > \n> > expecting success of 7422.18 'git submodule status --recursive propagates SIGPIPE':\n> > { git submodule status --recursive 2>err; echo $?>status; } |\n> > grep -q X/S &&\n> > test_must_be_empty err &&\n> > test_match_signal 13 \"$(cat status)\"\n> \n> I couldn't reproduce with --stress, but you can trigger it all the time\n> with:\n> \n> diff --git a/t/t7422-submodule-output.sh b/t/t7422-submodule-output.sh\n> index f21e920367..9338c75626 100755\n> --- a/t/t7422-submodule-output.sh\n> +++ b/t/t7422-submodule-output.sh\n> @@ -168,7 +168,7 @@ done\n> \n> test_expect_success !MINGW 'git submodule status --recursive propagates SIGPIPE' '\n> \t{ git submodule status --recursive 2>err; echo $?>status; } |\n> -\t\tgrep -q X/S &&\n> +\t\t{ sleep 1 && grep -q X/S; } &&\n> \ttest_must_be_empty err &&\n> \ttest_match_signal 13 \"$(cat status)\"\n> '\n> \n> The problem is that git-submodule may write all of its output before\n> grep exits, and it gets stored in the pipe buffer. And then even if grep\n> exits before reading all of it, it is too late for SIGPIPE, and the data\n> in the pipe is just discarded by the OS.\n> \n> So this:\n> \n> > The issue is caused by us using grep(1) to terminate the pipe on the\n> > first matching line in the recursing git-submodule(1) process. Standard\n> > streams are typically buffered though, so this condition is racy and may\n> > cause us to terminate the pipe after git-submodule(1) has already\n> > exited, and in that case we wouldn't see the expected signal.\n> > \n> > Fix the issue by converting standard streams to be unbuffered. I have\n> > only been able to reproduce this issue a single time after running t7422\n> > with `--stress` after an extended amount of time, so I cannot claim to\n> > be fully certain that this fix is sufficient.\n> \n> isn't quite right. Even without input buffering on grep's part, it may\n> be too slow to read the data. And adding a sleep as above shows that it\n> still fails with your patch.\n\nGreat. I was hoping to nerd-snipe somebody into helping me out with the\nlast sentence in my above paragraph :) Happy to see that you bit.\n\n> The usual way to reliably get SIGPIPE is to make sure the writer\n> produces enough data to fill the pipe buffer. But it's tricky to get\n> \"submodule status\" to produce a lot of data without having a ton of\n> submodules, which is expensive to set up.\n> \n> But we can hack around it by stuffing the pipe full with a separate\n> process. Like this:\n> \n> diff --git a/t/t7422-submodule-output.sh b/t/t7422-submodule-output.sh\n> index f21e920367..c4df2629e8 100755\n> --- a/t/t7422-submodule-output.sh\n> +++ b/t/t7422-submodule-output.sh\n> @@ -167,8 +167,15 @@ do\n> done\n> \n> test_expect_success !MINGW 'git submodule status --recursive propagates SIGPIPE' '\n> -\t{ git submodule status --recursive 2>err; echo $?>status; } |\n> -\t\tgrep -q X/S &&\n> +\t{\n> +\t\t# stuff pipe buffer full of input so that submodule status\n> +\t\t# will require blocking on write; this script will write over\n> +\t\t# 128kb. It might itself get SIGPIPE, so we must not &&-chain\n> +\t\t# it directly.\n> +\t\t{ perl -le \"print q{foo} for (1..33000)\" || true; } &&\n> +\t\tgit submodule status --recursive 2>err\n> +\t\techo $? >status\n> +\t} | { sleep 1 && head -n 1 >/dev/null; } &&\n> \ttest_must_be_empty err &&\n> \ttest_match_signal 13 \"$(cat status)\"\n> '\n> A few notes:\n> \n> - the sleep is still there to demonstrate that it always works, but\n> obviously we'd want to remove that\n\nNice, this indeed lets me reproduce the issue reliably.\n\n> - I swapped out \"grep\" for \"head\". What we are matching is not\n> relevant; the important thing is that the reader closes the pipe\n> immediately. So I guess in that sense we could probably even just\n> pipe to \"true\" or similar.\n\nI think the grep(1) is relevant though. The test explicitly verifies\nthat `--recursive` propagates SIGPIPE, so we must make sure that we\ntrigger the SIGPIPE when the child process produces output, not when the\nparent process produces it. That's why we grep for \"X/S\", where \"X\" is a\nsubmodule -- it means that we know that it is currently the subprocess\ndoing its thing.\n\nIt also simplifies the code a bit given that the call to Perl doesn't\nneed `|| true` anymore.\n\n> - I tried using test_seq to avoid the inline perl, but it doesn't\n> work! The problem is that it's implemented as a shell function. So\n> when it gets SIGPIPE, the whole subshell is killed, and we never\n> even run git-submodule at all. So it has to be a separate process\n> (though I guess it could be test_seq in a subshell).\n\nAnd that one should also work if we retain the grep. I wonder though\nwhether we shouldn't prefer to use Perl regardless as it's likely to be\nfaster when generating all that gibberish. Perl is basically a hard\nprerequisite for our tests anyway, so it doesn't really hurt to call it\nhere.\n\nPatrick\n"},{"id":"509975","messageId":"20250106-b4-pks-ci-fixes-v2-0-06ae540771b7@pks.im","threadId":"62731","inReplyTo":"20250103-b4-pks-ci-fixes-v1-0-a9bb95dff833@pks.im","subject":"[PATCH v2 00/10] A couple of CI improvements","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-06T11:16:49Z","receivedAt":"2025-01-06T11:16:55Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Hi,\n\nthis patch series addresses a couple of issues I've found while\ninvestigating flaky CI jobs. Besides two more fixes for flaky jobs it\nalso removes some stale code and simplifies the setup on GitHub Actions\nto always use containerized jobs on Linux.\n\nTest runs can be found for GitLab [1] and GitHub [2].\n\nChanges in v2:\n\n - Expand a bit on the reasoning behind the conversion to use\n containerized jobs.\n - Fix commit message typo.\n - Properly fix the race in t7422 via pipe stuffing, as proposed by\n Peff.\n - Link to v1: https://lore.kernel.org/r/20250103-b4-pks-ci-fixes-v1-0-a9bb95dff833@pks.im\n\nThanks!\n\nPatrick\n\n[1]: https://gitlab.com/gitlab-org/git/-/merge_requests/277\n[2]: https://github.com/git/git/pull/1865\n\n---\nPatrick Steinhardt (10):\n t0060: fix EBUSY in MinGW when setting up runtime prefix\n t7422: fix flaky test caused by buffered stdout\n github: adapt containerized jobs to be rootless\n github: convert all Linux jobs to be containerized\n github: simplify computation of the job's distro\n gitlab-ci: remove the \"linux-old\" job\n gitlab-ci: add linux32 job testing against i386\n ci: stop special-casing for Ubuntu 16.04\n ci: use latest Ubuntu release\n ci: remove stale code for Azure Pipelines\n\n .github/workflows/main.yml | 78 ++++++++++++++++++++++-----------------------\n .gitlab-ci.yml | 19 ++++++-----\n ci/install-dependencies.sh | 6 ++--\n ci/lib.sh | 34 +++-----------------\n ci/print-test-failures.sh | 5 ---\n t/t0060-path-utils.sh | 10 +++---\n t/t7422-submodule-output.sh | 10 ++++--\n 7 files changed, 69 insertions(+), 93 deletions(-)\n\nRange-diff versus v1:\n\n 1: 8ef1870c39 = 1: 14a80c2683 t0060: fix EBUSY in MinGW when setting up runtime prefix\n 2: f0647aad30 < -: ---------- t7422: fix flaky test caused by buffered stdout\n -: ---------- > 2: 967e76f482 t7422: fix flaky test caused by buffered stdout\n 3: 2768ecb60c = 3: bd2bae13e4 github: adapt containerized jobs to be rootless\n 4: 3a8aafdc32 ! 4: bc0bf7b8d5 github: convert all Linux jobs to be containerized\n @@ Commit message\n The latter is more flexible because it allows us to freely pick whatever\n container image we want to use for a specific job, while the former only\n allows us to pick from a handful of different distros. The containerized\n - jobs shouldn't cause a significant slowdown, either, so they do not have\n - any significant upside to the best of my knowlegde. The only upside that\n - they did have before the preceding commit is that they run as a non-root\n - user, but that has been addressed now.\n + jobs do not have any significant downsides to the best of my knowledge:\n \n - Convert all Linux jobs to be containerized for additional flexibility.\n + - They aren't significantly slower to start up. A quick comparison by\n + Peff shows that the difference is mostly lost in the noise:\n +\n + job | old | new\n + --------------------|------|------\n + linux-TEST-vars 11m30s 10m54s\n + linux-asan-ubsan 30m26s 31m14s\n + linux-gcc 9m47s 10m6s\n + linux-gcc-default 9m47s 9m41s\n + linux-leaks 25m50s 25m21s\n + linux-meson 10m36s 10m41s\n + linux-reftable 10m25s 10m23s\n + linux-reftable-leaks 27m18s 27m28s\n + linux-sha256 9m54s 10m31s\n +\n + Some jobs are a bit faster, some are a bit slower, but there does\n + not seem to be any significant change.\n +\n + - Containerized jobs run as root, which keeps a couple of tests from\n + running. This has been addressed in the preceding commit though,\n + where we now use setpriv(1) to run tests as a separate user.\n +\n + - GitHub injects a Node binary into containerized jobs, which is\n + dynamically linked. This has led to some issues in the past [1], but\n + only for our 32 bit jobs. The issues have since been resolved.\n +\n + Overall there seem to be no downsides, but the upside is that we have\n + more control over the exact image that these jobs use. Convert the Linux\n + jobs accordingly.\n +\n + [1]: https://lore.kernel.org/git/20240912094841.GD589828@coredump.intra.peff.net/\n \n Signed-off-by: Patrick Steinhardt \n \n 5: a50ee3dd9a ! 5: 22bd775ad0 github: simplify computation of the job's distro\n @@ Commit message\n \n There are a couple of exceptions:\n \n - - The \"linux32\" job, w whose distro name is different than the image\n + - The \"linux32\" job, whose distro name is different than the image\n name. This is handled by adapting all sites to use the new name.\n \n - The \"alpine\" and \"fedora\" jobs, neither of which specify a tag for\n 6: b31305597e = 6: ddce6be0b6 gitlab-ci: remove the \"linux-old\" job\n 7: dfa41f5593 = 7: 40a0c1e22a gitlab-ci: add linux32 job testing against i386\n 8: bd1efb0373 = 8: d775afb9c3 ci: stop special-casing for Ubuntu 16.04\n 9: fa505756a7 = 9: 0dd988643f ci: use latest Ubuntu release\n10: c64af8aa78 = 10: bdca84eebd ci: remove stale code for Azure Pipelines\n\n---\nbase-commit: 1b4e9a5f8b5f048972c21fe8acafe0404096f694\nchange-id: 20250103-b4-pks-ci-fixes-2d0a23fb5c78\n\n"},{"id":"509976","messageId":"20250106-b4-pks-ci-fixes-v2-1-06ae540771b7@pks.im","threadId":"62731","inReplyTo":"20250106-b4-pks-ci-fixes-v2-0-06ae540771b7@pks.im","subject":"[PATCH v2 01/10] t0060: fix EBUSY in MinGW when setting up runtime prefix","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-06T11:16:50Z","receivedAt":"2025-01-06T11:16:57Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Two of our tests in t0060 verify that the runtime prefix functionality\nworks as expected by creating a separate directory hierarchy, copying\nthe Git executable in there and then creating scripts relative to that\nexecutable.\n\nThese tests fail quite regularly in GitLab CI with the following error:\n\n expecting success of 0060.218 '%(prefix)/ works':\n mkdir -p pretend/bin &&\n cp \"$GIT_EXEC_PATH\"/git$X pretend/bin/ &&\n git config yes.path \"%(prefix)/yes\" &&\n GIT_EXEC_PATH= ./pretend/bin/git config --path yes.path >actual &&\n echo \"$(pwd)/pretend/yes\" >expect &&\n test_cmp expect actual\n ++ mkdir -p pretend/bin\n ++ cp /c/GitLab-Runner/builds/gitlab-org/git/git.exe pretend/bin/\n cp: cannot create regular file 'pretend/bin/git.exe': Device or resource busy\n error: last command exited with $?=1\n not ok 218 - %(prefix)/ works\n\nSeemingly, the \"git.exe\" binary we are trying to overwrite is still\nbeing held open. It is somewhat puzzling why exactly that is: while the\npreceding test _does_ write to and execute the same path, it should have\nexited and shouldn't keep any backgrounded processes around. So it must\nbe held open by something else, either in MinGW or in Windows itself.\n\nWhile the root cause is puzzling, the workaround is trivial enough:\ninstead of writing the file twice we simply pull the common setup into a\nseparate test case so that we won't observe EBUSY in the first place.\n\nSigned-off-by: Patrick Steinhardt \n---\n t/t0060-path-utils.sh | 10 ++++++----\n 1 file changed, 6 insertions(+), 4 deletions(-)\n\ndiff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh\nindex dbb2e73bcd912ae6a804603ff54e4c609966fa5d..8545cdfab559b4e247cb2699965e637529fd930a 100755\n--- a/t/t0060-path-utils.sh\n+++ b/t/t0060-path-utils.sh\n@@ -592,17 +592,19 @@ test_lazy_prereq CAN_EXEC_IN_PWD '\n \t./git rev-parse\n '\n \n+test_expect_success !VALGRIND,RUNTIME_PREFIX,CAN_EXEC_IN_PWD 'setup runtime prefix' '\n+\tmkdir -p pretend/bin &&\n+\tcp \"$GIT_EXEC_PATH\"/git$X pretend/bin/\n+'\n+\n test_expect_success !VALGRIND,RUNTIME_PREFIX,CAN_EXEC_IN_PWD 'RUNTIME_PREFIX works' '\n-\tmkdir -p pretend/bin pretend/libexec/git-core &&\n+\tmkdir -p pretend/libexec/git-core &&\n \techo \"echo HERE\" | write_script pretend/libexec/git-core/git-here &&\n-\tcp \"$GIT_EXEC_PATH\"/git$X pretend/bin/ &&\n \tGIT_EXEC_PATH= ./pretend/bin/git here >actual &&\n \techo HERE >expect &&\n \ttest_cmp expect actual'\n \n test_expect_success !VALGRIND,RUNTIME_PREFIX,CAN_EXEC_IN_PWD '%(prefix)/ works' '\n-\tmkdir -p pretend/bin &&\n-\tcp \"$GIT_EXEC_PATH\"/git$X pretend/bin/ &&\n \tgit config yes.path \"%(prefix)/yes\" &&\n \tGIT_EXEC_PATH= ./pretend/bin/git config --path yes.path >actual &&\n \techo \"$(pwd)/pretend/yes\" >expect &&\n\n-- \n2.48.0.rc1.245.gb3e6e7acbc.dirty\n\n"},{"id":"509977","messageId":"20250106-b4-pks-ci-fixes-v2-3-06ae540771b7@pks.im","threadId":"62731","inReplyTo":"20250106-b4-pks-ci-fixes-v2-0-06ae540771b7@pks.im","subject":"[PATCH v2 03/10] github: adapt containerized jobs to be rootless","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-06T11:16:52Z","receivedAt":"2025-01-06T11:16:57Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"The containerized jobs in GitHub Actions run as root, giving them\nspecial permissions to for example delete files even when the user\nshouldn't be able to due to file permissions. This limitation keeps us\nfrom using containerized jobs for most of our Ubuntu-based jobs as it\ncauses a number of tests to fail.\n\nAdapt the jobs to create a separate user that executes the test suite.\nThis follows similar infrastructure that we already have in GitLab CI.\n\nSigned-off-by: Patrick Steinhardt \n---\n .github/workflows/main.yml | 6 ++++--\n ci/install-dependencies.sh | 2 +-\n 2 files changed, 5 insertions(+), 3 deletions(-)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex 900be9957a23fcaa64e1aefd0c8638c5f84b7997..b02f5873a540b458d38e7951b4ee3d5ca598ae23 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -371,10 +371,12 @@ jobs:\n run: apt -q update && apt -q -y install libc6-amd64 lib64stdc++6\n - uses: actions/checkout@v4\n - run: ci/install-dependencies.sh\n- - run: ci/run-build-and-tests.sh\n+ - run: useradd builder --create-home\n+ - run: chown -R builder .\n+ - run: sudo --preserve-env --set-home --user=builder ci/run-build-and-tests.sh\n - name: print test failures\n if: failure() && env.FAILED_TEST_ARTIFACTS != ''\n- run: ci/print-test-failures.sh\n+ run: sudo --preserve-env --set-home --user=builder ci/print-test-failures.sh\n - name: Upload failed tests' directories\n if: failure() && env.FAILED_TEST_ARTIFACTS != ''\n uses: actions/upload-artifact@v4\ndiff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh\nindex d1cb9fa8785388b3674fcea4dd682abc0725c968..ecb5b9d36c20d3e7e96148ac628a96c62642c308 100755\n--- a/ci/install-dependencies.sh\n+++ b/ci/install-dependencies.sh\n@@ -31,7 +31,7 @@ alpine-*)\n \t;;\n fedora-*|almalinux-*)\n \tdnf -yq update >/dev/null &&\n-\tdnf -yq install make gcc findutils diffutils perl python3 gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null\n+\tdnf -yq install shadow-utils sudo make gcc findutils diffutils perl python3 gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null\n \t;;\n ubuntu-*|ubuntu32-*|debian-*)\n \t# Required so that apt doesn't wait for user input on certain packages.\n\n-- \n2.48.0.rc1.245.gb3e6e7acbc.dirty\n\n"},{"id":"509978","messageId":"20250106-b4-pks-ci-fixes-v2-2-06ae540771b7@pks.im","threadId":"62731","inReplyTo":"20250106-b4-pks-ci-fixes-v2-0-06ae540771b7@pks.im","subject":"[PATCH v2 02/10] t7422: fix flaky test caused by buffered stdout","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-06T11:16:51Z","receivedAt":"2025-01-06T11:16:58Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"One test in t7422 asserts that `git submodule status --recursive`\nproperly handles SIGPIPE. This test is flaky though and may sometimes\nnot see a SIGPIPE at all:\n\n expecting success of 7422.18 'git submodule status --recursive propagates SIGPIPE':\n { git submodule status --recursive 2>err; echo $?>status; } |\n grep -q X/S &&\n test_must_be_empty err &&\n test_match_signal 13 \"$(cat status)\"\n ++ git submodule status --recursive\n ++ grep -q X/S\n ++ echo 0\n ++ test_must_be_empty err\n ++ test 1 -ne 1\n ++ test_path_is_file err\n ++ test 1 -ne 1\n ++ test -f err\n ++ test -s err\n +++ cat status\n ++ test_match_signal 13 0\n ++ test 0 = 141\n ++ test 0 = 269\n ++ return 1\n error: last command exited with $?=1\n not ok 18 - git submodule status --recursive propagates SIGPIPE\n\nThe issue is caused by us using grep(1) to terminate the pipe on the\nfirst matching line in the recursing git-submodule(1) process. Standard\nstreams are typically buffered though, so this condition is racy and may\ncause us to terminate the pipe after git-submodule(1) has already\nexited, and in that case we wouldn't see the expected signal.\n\nFix the issue by making the writer fill the pipe buffer before we\nexecute git-submodule(1). Ideally, it would be git-submodule(1) itself\nthat does produce all that data, but it would require us to create a\nlarge amount of submodules, which is inefficient. Instead, we use Perl\nto print gibberish until the buffer is filled.\n\nTo verify that this works as expected one can apply the following patch\nto the preimage of this commit, which used to reliably trigger the race:\n\n diff --git a/t/t7422-submodule-output.sh b/t/t7422-submodule-output.sh\n index f21e920367..9338c75626 100755\n --- a/t/t7422-submodule-output.sh\n +++ b/t/t7422-submodule-output.sh\n @@ -168,7 +168,7 @@ done\n\n test_expect_success !MINGW 'git submodule status --recursive propagates SIGPIPE' '\n { git submodule status --recursive 2>err; echo $?>status; } |\n -\t\tgrep -q X/S &&\n +\t\t{ sleep 1 && grep -q X/S; } &&\n test_must_be_empty err &&\n test_match_signal 13 \"$(cat status)\"\n '\n\nWith the pipe-stuffing workaround the test runs successfully.\n\nHelped-by: Jeff King \nSigned-off-by: Patrick Steinhardt \n---\n t/t7422-submodule-output.sh | 10 ++++++++--\n 1 file changed, 8 insertions(+), 2 deletions(-)\n\ndiff --git a/t/t7422-submodule-output.sh b/t/t7422-submodule-output.sh\nindex f21e9203678b94701281d5339ae8bfe53d5de0ed..976f91b0ebd9d82daee3802a212dd3f4031fe86b 100755\n--- a/t/t7422-submodule-output.sh\n+++ b/t/t7422-submodule-output.sh\n@@ -167,8 +167,14 @@ do\n done\n \n test_expect_success !MINGW 'git submodule status --recursive propagates SIGPIPE' '\n-\t{ git submodule status --recursive 2>err; echo $?>status; } |\n-\t\tgrep -q X/S &&\n+\t{\n+\t\t# Stuff pipe buffer full of input so that `git submodule\n+\t\t# status` will block on write; this script will write over\n+\t\t# 128kb.\n+\t\tperl -le \"print q{foo} for (1..33000)\" &&\n+\t\tgit submodule status --recursive 2>err\n+\t\techo $?>status\n+\t} | grep -q X/S &&\n \ttest_must_be_empty err &&\n \ttest_match_signal 13 \"$(cat status)\"\n '\n\n-- \n2.48.0.rc1.245.gb3e6e7acbc.dirty\n\n"},{"id":"509979","messageId":"20250106-b4-pks-ci-fixes-v2-4-06ae540771b7@pks.im","threadId":"62731","inReplyTo":"20250106-b4-pks-ci-fixes-v2-0-06ae540771b7@pks.im","subject":"[PATCH v2 04/10] github: convert all Linux jobs to be containerized","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-06T11:16:53Z","receivedAt":"2025-01-06T11:16:58Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"We have split the CI jobs in GitHub Workflows into two categories:\n\n - Those running on a machine pool directly.\n\n - Those running in a container on the machine pool.\n\nThe latter is more flexible because it allows us to freely pick whatever\ncontainer image we want to use for a specific job, while the former only\nallows us to pick from a handful of different distros. The containerized\njobs do not have any significant downsides to the best of my knowledge:\n\n - They aren't significantly slower to start up. A quick comparison by\n Peff shows that the difference is mostly lost in the noise:\n\n job | old | new\n --------------------|------|------\n linux-TEST-vars 11m30s 10m54s\n linux-asan-ubsan 30m26s 31m14s\n linux-gcc 9m47s 10m6s\n linux-gcc-default 9m47s 9m41s\n linux-leaks 25m50s 25m21s\n linux-meson 10m36s 10m41s\n linux-reftable 10m25s 10m23s\n linux-reftable-leaks 27m18s 27m28s\n linux-sha256 9m54s 10m31s\n\n Some jobs are a bit faster, some are a bit slower, but there does\n not seem to be any significant change.\n\n - Containerized jobs run as root, which keeps a couple of tests from\n running. This has been addressed in the preceding commit though,\n where we now use setpriv(1) to run tests as a separate user.\n\n - GitHub injects a Node binary into containerized jobs, which is\n dynamically linked. This has led to some issues in the past [1], but\n only for our 32 bit jobs. The issues have since been resolved.\n\nOverall there seem to be no downsides, but the upside is that we have\nmore control over the exact image that these jobs use. Convert the Linux\njobs accordingly.\n\n[1]: https://lore.kernel.org/git/20240912094841.GD589828@coredump.intra.peff.net/\n\nSigned-off-by: Patrick Steinhardt \n---\n .github/workflows/main.yml | 68 ++++++++++++++++++++++++++--------------------\n 1 file changed, 39 insertions(+), 29 deletions(-)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex b02f5873a540b458d38e7951b4ee3d5ca598ae23..8e5847da4fab009ad699c18e1a5a336a8b45c3ed 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -259,20 +259,6 @@ jobs:\n fail-fast: false\n matrix:\n vector:\n- - jobname: linux-sha256\n- cc: clang\n- pool: ubuntu-latest\n- - jobname: linux-reftable\n- cc: clang\n- pool: ubuntu-latest\n- - jobname: linux-gcc\n- cc: gcc\n- cc_package: gcc-8\n- pool: ubuntu-20.04\n- - jobname: linux-TEST-vars\n- cc: gcc\n- cc_package: gcc-8\n- pool: ubuntu-20.04\n - jobname: osx-clang\n cc: clang\n pool: macos-13\n@@ -285,21 +271,6 @@ jobs:\n - jobname: osx-meson\n cc: clang\n pool: macos-13\n- - jobname: linux-gcc-default\n- cc: gcc\n- pool: ubuntu-latest\n- - jobname: linux-leaks\n- cc: gcc\n- pool: ubuntu-latest\n- - jobname: linux-reftable-leaks\n- cc: gcc\n- pool: ubuntu-latest\n- - jobname: linux-asan-ubsan\n- cc: clang\n- pool: ubuntu-latest\n- - jobname: linux-meson\n- cc: gcc\n- pool: ubuntu-latest\n env:\n CC: ${{matrix.vector.cc}}\n CC_PACKAGE: ${{matrix.vector.cc_package}}\n@@ -342,6 +313,44 @@ jobs:\n fail-fast: false\n matrix:\n vector:\n+ - jobname: linux-sha256\n+ image: ubuntu:latest\n+ cc: clang\n+ distro: ubuntu-latest\n+ - jobname: linux-reftable\n+ image: ubuntu:latest\n+ cc: clang\n+ distro: ubuntu-latest\n+ - jobname: linux-gcc\n+ image: ubuntu:20.04\n+ cc: gcc\n+ cc_package: gcc-8\n+ distro: ubuntu-20.04\n+ - jobname: linux-TEST-vars\n+ image: ubuntu:20.04\n+ cc: gcc\n+ cc_package: gcc-8\n+ distro: ubuntu-20.04\n+ - jobname: linux-gcc-default\n+ image: ubuntu:latest\n+ cc: gcc\n+ distro: ubuntu-latest\n+ - jobname: linux-leaks\n+ image: ubuntu:latest\n+ cc: gcc\n+ distro: ubuntu-latest\n+ - jobname: linux-reftable-leaks\n+ image: ubuntu:latest\n+ cc: gcc\n+ distro: ubuntu-latest\n+ - jobname: linux-asan-ubsan\n+ image: ubuntu:latest\n+ cc: clang\n+ distro: ubuntu-latest\n+ - jobname: linux-meson\n+ image: ubuntu:latest\n+ cc: gcc\n+ distro: ubuntu-latest\n - jobname: linux-musl\n image: alpine\n distro: alpine-latest\n@@ -363,6 +372,7 @@ jobs:\n env:\n jobname: ${{matrix.vector.jobname}}\n distro: ${{matrix.vector.distro}}\n+ CC: ${{matrix.vector.cc}}\n runs-on: ubuntu-latest\n container: ${{matrix.vector.image}}\n steps:\n\n-- \n2.48.0.rc1.245.gb3e6e7acbc.dirty\n\n"},{"id":"509980","messageId":"20250106-b4-pks-ci-fixes-v2-6-06ae540771b7@pks.im","threadId":"62731","inReplyTo":"20250106-b4-pks-ci-fixes-v2-0-06ae540771b7@pks.im","subject":"[PATCH v2 06/10] gitlab-ci: remove the \"linux-old\" job","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-06T11:16:55Z","receivedAt":"2025-01-06T11:17:00Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"The \"linux-old\" job was historically testing against the oldest\nsupported LTS release of Ubuntu. But with c85bcb5de1 (gitlab-ci: switch\nfrom Ubuntu 16.04 to 20.04, 2024-10-31) it has been converted to test\nagainst Ubuntu 20.04, which already gets exercised in a couple of other\nCI jobs. It's thus not adding any significant test coverage.\n\nDrop the job.\n\nSigned-off-by: Patrick Steinhardt \n---\n .gitlab-ci.yml | 3 ---\n 1 file changed, 3 deletions(-)\n\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 9254e01583306e67dc12b6b9e0015183e1108655..00bc727865031620752771af4a9030c7de1b73df 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -36,9 +36,6 @@ test:linux:\n fi\n parallel:\n matrix:\n- - jobname: linux-old\n- image: ubuntu:20.04\n- CC: gcc\n - jobname: linux-sha256\n image: ubuntu:latest\n CC: clang\n\n-- \n2.48.0.rc1.245.gb3e6e7acbc.dirty\n\n"},{"id":"509981","messageId":"20250106-b4-pks-ci-fixes-v2-5-06ae540771b7@pks.im","threadId":"62731","inReplyTo":"20250106-b4-pks-ci-fixes-v2-0-06ae540771b7@pks.im","subject":"[PATCH v2 05/10] github: simplify computation of the job's distro","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-06T11:16:54Z","receivedAt":"2025-01-06T11:17:00Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"We explicitly list the distro of Linux-based jobs, but it is equivalent\nto the name of the image in almost all cases, except that colons are\nreplaced with dashes. Drop the redundant information and massage it in\nour CI scripts, which is equivalent to how we do it in GitLab CI.\n\nThere are a couple of exceptions:\n\n - The \"linux32\" job, whose distro name is different than the image\n name. This is handled by adapting all sites to use the new name.\n\n - The \"alpine\" and \"fedora\" jobs, neither of which specify a tag for\n their image. This is handled by adding the \"latest\" tag.\n\nSigned-off-by: Patrick Steinhardt \n---\n .github/workflows/main.yml | 22 ++++------------------\n ci/install-dependencies.sh | 4 ++--\n ci/lib.sh | 2 ++\n 3 files changed, 8 insertions(+), 20 deletions(-)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex 8e5847da4fab009ad699c18e1a5a336a8b45c3ed..b54da639a650682495994e3c7b137eab4e6cb3bf 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -275,7 +275,7 @@ jobs:\n CC: ${{matrix.vector.cc}}\n CC_PACKAGE: ${{matrix.vector.cc_package}}\n jobname: ${{matrix.vector.jobname}}\n- distro: ${{matrix.vector.pool}}\n+ CI_JOB_IMAGE: ${{matrix.vector.pool}}\n TEST_OUTPUT_DIRECTORY: ${{github.workspace}}/t\n runs-on: ${{matrix.vector.pool}}\n steps:\n@@ -316,63 +316,49 @@ jobs:\n - jobname: linux-sha256\n image: ubuntu:latest\n cc: clang\n- distro: ubuntu-latest\n - jobname: linux-reftable\n image: ubuntu:latest\n cc: clang\n- distro: ubuntu-latest\n - jobname: linux-gcc\n image: ubuntu:20.04\n cc: gcc\n cc_package: gcc-8\n- distro: ubuntu-20.04\n - jobname: linux-TEST-vars\n image: ubuntu:20.04\n cc: gcc\n cc_package: gcc-8\n- distro: ubuntu-20.04\n - jobname: linux-gcc-default\n image: ubuntu:latest\n cc: gcc\n- distro: ubuntu-latest\n - jobname: linux-leaks\n image: ubuntu:latest\n cc: gcc\n- distro: ubuntu-latest\n - jobname: linux-reftable-leaks\n image: ubuntu:latest\n cc: gcc\n- distro: ubuntu-latest\n - jobname: linux-asan-ubsan\n image: ubuntu:latest\n cc: clang\n- distro: ubuntu-latest\n - jobname: linux-meson\n image: ubuntu:latest\n cc: gcc\n- distro: ubuntu-latest\n - jobname: linux-musl\n- image: alpine\n- distro: alpine-latest\n+ image: alpine:latest\n # Supported until 2025-04-02.\n - jobname: linux32\n image: i386/ubuntu:focal\n- distro: ubuntu32-20.04\n - jobname: pedantic\n- image: fedora\n- distro: fedora-latest\n+ image: fedora:latest\n # A RHEL 8 compatible distro. Supported until 2029-05-31.\n - jobname: almalinux-8\n image: almalinux:8\n- distro: almalinux-8\n # Supported until 2026-08-31.\n - jobname: debian-11\n image: debian:11\n- distro: debian-11\n env:\n jobname: ${{matrix.vector.jobname}}\n- distro: ${{matrix.vector.distro}}\n CC: ${{matrix.vector.cc}}\n+ CI_JOB_IMAGE: ${{matrix.vector.image}}\n runs-on: ubuntu-latest\n container: ${{matrix.vector.image}}\n steps:\ndiff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh\nindex ecb5b9d36c20d3e7e96148ac628a96c62642c308..d5a959e25ff3236656ff3416b81732ec5c2107c1 100755\n--- a/ci/install-dependencies.sh\n+++ b/ci/install-dependencies.sh\n@@ -33,7 +33,7 @@ fedora-*|almalinux-*)\n \tdnf -yq update >/dev/null &&\n \tdnf -yq install shadow-utils sudo make gcc findutils diffutils perl python3 gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null\n \t;;\n-ubuntu-*|ubuntu32-*|debian-*)\n+ubuntu-*|i386/ubuntu-*|debian-*)\n \t# Required so that apt doesn't wait for user input on certain packages.\n \texport DEBIAN_FRONTEND=noninteractive\n \n@@ -42,7 +42,7 @@ ubuntu-*|ubuntu32-*|debian-*)\n \t\tSVN='libsvn-perl subversion'\n \t\tLANGUAGES='language-pack-is'\n \t\t;;\n-\tubuntu32-*)\n+\ti386/ubuntu-*)\n \t\tSVN=\n \t\tLANGUAGES='language-pack-is'\n \t\t;;\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex 8885ee3c3f86c62e8783d27756b8779bd491e7e6..f8b68ab8a6546802756fd516ca15a2c97223da5f 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -246,6 +246,8 @@ then\n \n \tGIT_TEST_OPTS=\"--github-workflow-markup\"\n \tJOBS=10\n+\n+\tdistro=$(echo \"$CI_JOB_IMAGE\" | tr : -)\n elif test true = \"$GITLAB_CI\"\n then\n \tCI_TYPE=gitlab-ci\n\n-- \n2.48.0.rc1.245.gb3e6e7acbc.dirty\n\n"},{"id":"509982","messageId":"20250106-b4-pks-ci-fixes-v2-7-06ae540771b7@pks.im","threadId":"62731","inReplyTo":"20250106-b4-pks-ci-fixes-v2-0-06ae540771b7@pks.im","subject":"[PATCH v2 07/10] gitlab-ci: add linux32 job testing against i386","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-06T11:16:56Z","receivedAt":"2025-01-06T11:17:01Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Add another job to GitLab CI that tests against the i386 architecture.\nThis job is equivalent to the same job in GitHub Workflows.\n\nSigned-off-by: Patrick Steinhardt \n---\n .gitlab-ci.yml | 2 ++\n ci/lib.sh | 2 +-\n 2 files changed, 3 insertions(+), 1 deletion(-)\n\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 00bc727865031620752771af4a9030c7de1b73df..29e9056dd5010f8843e42aeae8410973c825de54 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -66,6 +66,8 @@ test:linux:\n image: fedora:latest\n - jobname: linux-musl\n image: alpine:latest\n+ - jobname: linux32\n+ image: i386/ubuntu:20.04\n - jobname: linux-meson\n image: ubuntu:latest\n CC: gcc\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex f8b68ab8a6546802756fd516ca15a2c97223da5f..2293849ada3b45873f80e4392ab93c65657d0f13 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -269,7 +269,7 @@ then\n \t\tCI_OS_NAME=osx\n \t\tJOBS=$(nproc)\n \t\t;;\n-\t*,alpine:*|*,fedora:*|*,ubuntu:*)\n+\t*,alpine:*|*,fedora:*|*,ubuntu:*|*,i386/ubuntu:*)\n \t\tCI_OS_NAME=linux\n \t\tJOBS=$(nproc)\n \t\t;;\n\n-- \n2.48.0.rc1.245.gb3e6e7acbc.dirty\n\n"},{"id":"509983","messageId":"20250106-b4-pks-ci-fixes-v2-9-06ae540771b7@pks.im","threadId":"62731","inReplyTo":"20250106-b4-pks-ci-fixes-v2-0-06ae540771b7@pks.im","subject":"[PATCH v2 09/10] ci: use latest Ubuntu release","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-06T11:16:58Z","receivedAt":"2025-01-06T11:17:02Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Both GitHub Actions and GitLab CI use the \"ubuntu:latest\" tag as the\ndefault image for most jobs. This tag is somewhat misleading though, as\nit does not refer to the latest release of Ubuntu, but to the latest LTS\nrelease thereof. But as we already have a couple of jobs exercising the\noldest LTS release of Ubuntu that Git still supports, it would make more\nsense to test the oldest and youngest versions of Ubuntu.\n\nAdapt these jobs to instead use the \"ubuntu:rolling\" tag, which refers\nto the actual latest release, which currently is Ubuntu 24.10.\n\nSigned-off-by: Patrick Steinhardt \n---\n .github/workflows/main.yml | 14 +++++++-------\n .gitlab-ci.yml | 14 +++++++-------\n 2 files changed, 14 insertions(+), 14 deletions(-)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex b54da639a650682495994e3c7b137eab4e6cb3bf..b90381ae015edf9db5aa4b8c0ace9bb5c549c37b 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -314,10 +314,10 @@ jobs:\n matrix:\n vector:\n - jobname: linux-sha256\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n cc: clang\n - jobname: linux-reftable\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n cc: clang\n - jobname: linux-gcc\n image: ubuntu:20.04\n@@ -328,19 +328,19 @@ jobs:\n cc: gcc\n cc_package: gcc-8\n - jobname: linux-gcc-default\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n cc: gcc\n - jobname: linux-leaks\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n cc: gcc\n - jobname: linux-reftable-leaks\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n cc: gcc\n - jobname: linux-asan-ubsan\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n cc: clang\n - jobname: linux-meson\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n cc: gcc\n - jobname: linux-musl\n image: alpine:latest\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 29e9056dd5010f8843e42aeae8410973c825de54..8ed3ff5f0373d70b6f609dc5292dda2dd7fd8f88 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -37,10 +37,10 @@ test:linux:\n parallel:\n matrix:\n - jobname: linux-sha256\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n CC: clang\n - jobname: linux-reftable\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n CC: clang\n - jobname: linux-gcc\n image: ubuntu:20.04\n@@ -51,16 +51,16 @@ test:linux:\n CC: gcc\n CC_PACKAGE: gcc-8\n - jobname: linux-gcc-default\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n CC: gcc\n - jobname: linux-leaks\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n CC: gcc\n - jobname: linux-reftable-leaks\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n CC: gcc\n - jobname: linux-asan-ubsan\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n CC: clang\n - jobname: pedantic\n image: fedora:latest\n@@ -69,7 +69,7 @@ test:linux:\n - jobname: linux32\n image: i386/ubuntu:20.04\n - jobname: linux-meson\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n CC: gcc\n artifacts:\n paths:\n\n-- \n2.48.0.rc1.245.gb3e6e7acbc.dirty\n\n"},{"id":"509984","messageId":"20250106-b4-pks-ci-fixes-v2-8-06ae540771b7@pks.im","threadId":"62731","inReplyTo":"20250106-b4-pks-ci-fixes-v2-0-06ae540771b7@pks.im","subject":"[PATCH v2 08/10] ci: stop special-casing for Ubuntu 16.04","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-06T11:16:57Z","receivedAt":"2025-01-06T11:17:02Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"With c85bcb5de1 (gitlab-ci: switch from Ubuntu 16.04 to 20.04,\n2024-10-31) we have adapted the last CI job to stop using Ubuntu 16.04\nin favor of Ubuntu 20.04. Remove the special-casing we still have in our\nCI scripts.\n\nSigned-off-by: Patrick Steinhardt \n---\n ci/lib.sh | 9 +--------\n 1 file changed, 1 insertion(+), 8 deletions(-)\n\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex 2293849ada3b45873f80e4392ab93c65657d0f13..77a4aabdb8fb416c1733f02d02145b6bc0849998 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -347,14 +347,7 @@ ubuntu-*)\n \tfi\n \tMAKEFLAGS=\"$MAKEFLAGS PYTHON_PATH=/usr/bin/$PYTHON_PACKAGE\"\n \n-\tcase \"$distro\" in\n-\tubuntu-16.04)\n-\t\t# Apache is too old for HTTP/2.\n-\t\t;;\n-\t*)\n-\t\texport GIT_TEST_HTTPD=true\n-\t\t;;\n-\tesac\n+\texport GIT_TEST_HTTPD=true\n \n \t# The Linux build installs the defined dependency versions below.\n \t# The OS X build installs much more recent versions, whichever\n\n-- \n2.48.0.rc1.245.gb3e6e7acbc.dirty\n\n"},{"id":"509985","messageId":"20250106-b4-pks-ci-fixes-v2-10-06ae540771b7@pks.im","threadId":"62731","inReplyTo":"20250106-b4-pks-ci-fixes-v2-0-06ae540771b7@pks.im","subject":"[PATCH v2 10/10] ci: remove stale code for Azure Pipelines","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-06T11:16:59Z","receivedAt":"2025-01-06T11:17:04Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Support for Azure Pipelines has been retired in 6081d3898f (ci: retire\nthe Azure Pipelines definition, 2020-04-11) in favor of GitHub Actions.\nOur CI library still has some infrastructure left for Azure though that\nis now unused. Remove it.\n\nSigned-off-by: Patrick Steinhardt \n---\n ci/lib.sh | 21 +--------------------\n ci/print-test-failures.sh | 5 -----\n 2 files changed, 1 insertion(+), 25 deletions(-)\n\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex 77a4aabdb8fb416c1733f02d02145b6bc0849998..4003354f16c048b969c0bb4340d2ee2777767300 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -206,26 +206,7 @@ export TERM=${TERM:-dumb}\n # Clear MAKEFLAGS that may come from the outside world.\n export MAKEFLAGS=\n \n-if test -n \"$SYSTEM_COLLECTIONURI\" || test -n \"$SYSTEM_TASKDEFINITIONSURI\"\n-then\n-\tCI_TYPE=azure-pipelines\n-\t# We are running in Azure Pipelines\n-\tCI_BRANCH=\"$BUILD_SOURCEBRANCH\"\n-\tCI_COMMIT=\"$BUILD_SOURCEVERSION\"\n-\tCI_JOB_ID=\"$BUILD_BUILDID\"\n-\tCI_JOB_NUMBER=\"$BUILD_BUILDNUMBER\"\n-\tCI_OS_NAME=\"$(echo \"$AGENT_OS\" | tr A-Z a-z)\"\n-\ttest darwin != \"$CI_OS_NAME\" || CI_OS_NAME=osx\n-\tCI_REPO_SLUG=\"$(expr \"$BUILD_REPOSITORY_URI\" : '.*/\\([^/]*/[^/]*\\)$')\"\n-\tCC=\"${CC:-gcc}\"\n-\n-\t# use a subdirectory of the cache dir (because the file share is shared\n-\t# among *all* phases)\n-\tcache_dir=\"$HOME/test-cache/$SYSTEM_PHASENAME\"\n-\n-\tGIT_TEST_OPTS=\"--write-junit-xml\"\n-\tJOBS=10\n-elif test true = \"$GITHUB_ACTIONS\"\n+if test true = \"$GITHUB_ACTIONS\"\n then\n \tCI_TYPE=github-actions\n \tCI_BRANCH=\"$GITHUB_REF\"\ndiff --git a/ci/print-test-failures.sh b/ci/print-test-failures.sh\nindex 655687dd827e5b3e4d4879803b0d4499e7751380..dc910e51609cd7344b1ad03fdb4e820e47ad3a88 100755\n--- a/ci/print-test-failures.sh\n+++ b/ci/print-test-failures.sh\n@@ -39,11 +39,6 @@ do\n \t\ttest_name=\"${test_name##*/}\"\n \t\ttrash_dir=\"trash directory.$test_name\"\n \t\tcase \"$CI_TYPE\" in\n-\t\tazure-pipelines)\n-\t\t\tmkdir -p failed-test-artifacts\n-\t\t\tmv \"$trash_dir\" failed-test-artifacts\n-\t\t\tcontinue\n-\t\t\t;;\n \t\tgithub-actions)\n \t\t\tmkdir -p failed-test-artifacts\n \t\t\techo \"FAILED_TEST_ARTIFACTS=${TEST_OUTPUT_DIRECTORY:t}/failed-test-artifacts\" >>$GITHUB_ENV\n\n-- \n2.48.0.rc1.245.gb3e6e7acbc.dirty\n\n"},{"id":"510040","messageId":"20250107023904.GB2363@coredump.intra.peff.net","threadId":"62731","inReplyTo":"Z3u6lj_bpM7N93Fd@pks.im","subject":"Re: [PATCH 02/10] t7422: fix flaky test caused by buffered stdout","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-01-07T02:39:04Z","receivedAt":"2025-01-07T02:39:05Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 06, 2025 at 12:12:22PM +0100, Patrick Steinhardt wrote:\n\n> > isn't quite right. Even without input buffering on grep's part, it may\n> > be too slow to read the data. And adding a sleep as above shows that it\n> > still fails with your patch.\n> \n> Great. I was hoping to nerd-snipe somebody into helping me out with the\n> last sentence in my above paragraph :) Happy to see that you bit.\n\nI think I am a sucker for SIGPIPE races.\n\n> > - I swapped out \"grep\" for \"head\". What we are matching is not\n> > relevant; the important thing is that the reader closes the pipe\n> > immediately. So I guess in that sense we could probably even just\n> > pipe to \"true\" or similar.\n> \n> I think the grep(1) is relevant though. The test explicitly verifies\n> that `--recursive` propagates SIGPIPE, so we must make sure that we\n> trigger the SIGPIPE when the child process produces output, not when the\n> parent process produces it. That's why we grep for \"X/S\", where \"X\" is a\n> submodule -- it means that we know that it is currently the subprocess\n> doing its thing.\n\nHmm, I see what you mean. I don't think we can do that reliably, though,\nor that the perl byte-stuffing is actually helping.\n\nAs I wrote it, perl always gets SIGPIPE first (because either \"head\"\nexits while it is writing, or it fills up the pipe buffer and blocks,\nwaiting for head to exit, and then sees the pipe close).\n\nAnd thus when we run git-submodule, the pipe is reliably closed and\nwe'll see SIGPIPE.\n\nBut with grep, that does not happen. The grep will run through all of\nthe data from perl (since it does not contain X/S), and there will not\nbe anything left in the pipe buffer by the time git-submodule starts. So\nall of that data did nothing (though it fools the \"sleep 1 && grep\" from\nlosing the race because perl will block until grep starts, after the\nsleep is finished).\n\nAnd so we're left with the same race as before. git-submodule writes the\nX/S line, grep reads it and then tries to exit while git-submodule is\nwriting more. And either:\n\n a. grep may exit immediately, before git-submodule writes any more\n data. In which case git sees SIGPIPE, which is what we want.\n\n a. git-submodule may write all of its data before grep exits. It will\n not block, because all of the stuff perl put in the buffer is long\n since gone, having been read by grep already. The data goes into\n the pipe buffer, and git-submodule has no idea it is discarded when\n grep exits. The test fails.\n\nIt's hard to simulate this one with a sleep, because it requires either\ngit-submodule to write quickly, or for grep to be slow after reading the\nmatching line but before exiting.\n\nFor the latter you can do:\n\ndiff --git a/t/t7422-submodule-output.sh b/t/t7422-submodule-output.sh\nindex 976f91b0eb..e2961e57dc 100755\n--- a/t/t7422-submodule-output.sh\n+++ b/t/t7422-submodule-output.sh\n@@ -174,7 +174,7 @@ test_expect_success !MINGW 'git submodule status --recursive propagates SIGPIPE'\n \t\tperl -le \"print q{foo} for (1..33000)\" &&\n \t\tgit submodule status --recursive 2>err\n \t\techo $?>status\n-\t} | grep -q X/S &&\n+\t} | { grep -q X/S && sleep 1; } &&\n \ttest_must_be_empty err &&\n \ttest_match_signal 13 \"$(cat status)\"\n '\n\non top of your patch, which reliably fails the test. I know that looks\nkind of ridiculous and fake, but you can imagine it as that first grep\njust taking a long time to call exit() and close the pipe.\n\nIt's hard to make git-submodule faster, because its output is really\ncoming from recursive invocations of itself. But you could imagine a\nworld where we do the submodule recursion in a single process, buffering\nit via stdio, and then write all of the lines at once. And then\ngit-submodule always wins the race (it issues a single write() syscall\nand then exits), and the test fails.\n\nTo make the test reliable, you'd need to pause or fill the pipe buffer\n_after_ writing X/S via git-submodule but before writing the rest of the\ndata. Or to perhaps convince git-submodule only to write the recursive\ndata, and then pre-stuff the pipe as I suggested earlier. But I'm not\nsure how to do the latter. Even if we ask for:\n\n git submodule status --recursive -- X\n\nit will print out the status of \"X\" before recursing into it to show\nX/S, etc, which will give us SIGPIPE in the parent submodule process,\nnot the recursive one.\n\nFor the former, I guess you'd need some hook that runs when we recurse\ninto the submodule and dumps a bunch of garbage into the pipe buffer.\nBut I don't think there is any such hook that runs here. Unless perhaps\nyou abused core.fsmonitor or something, but I don't think that's\nportable.\n\nSo I don't really see a way to do this robustly.\n\n-Peff\n"},{"id":"510041","messageId":"20250107024829.GC2363@coredump.intra.peff.net","threadId":"62731","inReplyTo":"Z3u6lj_bpM7N93Fd@pks.im","subject":"Re: [PATCH 02/10] t7422: fix flaky test caused by buffered stdout","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-01-07T02:48:29Z","receivedAt":"2025-01-07T02:48:30Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 06, 2025 at 12:12:22PM +0100, Patrick Steinhardt wrote:\n\n> > - I tried using test_seq to avoid the inline perl, but it doesn't\n> > work! The problem is that it's implemented as a shell function. So\n> > when it gets SIGPIPE, the whole subshell is killed, and we never\n> > even run git-submodule at all. So it has to be a separate process\n> > (though I guess it could be test_seq in a subshell).\n> \n> And that one should also work if we retain the grep. I wonder though\n> whether we shouldn't prefer to use Perl regardless as it's likely to be\n> faster when generating all that gibberish. Perl is basically a hard\n> prerequisite for our tests anyway, so it doesn't really hurt to call it\n> here.\n\nI don't think we should pursue this direction any more because we need\nto get the SIGPIPE mid-way through the git-submodule command (see the\nother message I just sent).\n\nBut because it is a basic technique for establishing a reliable SIGPIPE,\nand we might end up using it elsewhere, I thought I'd post a slightly\nimproved version.\n\nThe two things I didn't like about what I posted earlier were:\n\n - the guess at the pipe buffer size. 128k is probably enough in\n practice, but it's not guaranteed.\n\n - piping to \"head\" actually made our buffer size guess worse. We know\n that \"head\" is going to read the first line and then exit. But how\n much more data might it read? It might easily buffer 4k or even 8k,\n leaving the buffer not-quite full.\n\nSo I think a simpler and more robust version is just this:\n\n {\n\t{ yes || true; } &&\n\tcommand_expecting_sigpipe; echo $? >status\n } | true\n\nWe'll keep producing data in \"yes\" until the pipe is closed. So it will\nclosed before command_expecting_sigpipe even starts, and there is no\nrace there. And because we're using \"true\" on the right-hand side of the\npipe, nothing is read at all from the pipe. So there's no guessing about\nhow much might have been read.\n\nAnd it works no matter how slow the right-hand side of the pipe is\n(e.g., you can add a \"sleep 1\" there and it still works).\n\nLike I said, this won't help our current situation, but after having\nspent a little time on it (before realizing that) I figured it was worth\ndocumenting.\n\n-Peff\n"},{"id":"510042","messageId":"20250107024951.GD2363@coredump.intra.peff.net","threadId":"62731","inReplyTo":"20250106-b4-pks-ci-fixes-v2-2-06ae540771b7@pks.im","subject":"Re: [PATCH v2 02/10] t7422: fix flaky test caused by buffered stdout","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-01-07T02:49:51Z","receivedAt":"2025-01-07T02:49:52Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 06, 2025 at 12:16:51PM +0100, Patrick Steinhardt wrote:\n\n> Fix the issue by making the writer fill the pipe buffer before we\n> execute git-submodule(1). Ideally, it would be git-submodule(1) itself\n> that does produce all that data, but it would require us to create a\n> large amount of submodules, which is inefficient. Instead, we use Perl\n> to print gibberish until the buffer is filled.\n> \n> To verify that this works as expected one can apply the following patch\n> to the preimage of this commit, which used to reliably trigger the race:\n> \n> diff --git a/t/t7422-submodule-output.sh b/t/t7422-submodule-output.sh\n> index f21e920367..9338c75626 100755\n> --- a/t/t7422-submodule-output.sh\n> +++ b/t/t7422-submodule-output.sh\n> @@ -168,7 +168,7 @@ done\n> \n> test_expect_success !MINGW 'git submodule status --recursive propagates SIGPIPE' '\n> { git submodule status --recursive 2>err; echo $?>status; } |\n> -\t\tgrep -q X/S &&\n> +\t\t{ sleep 1 && grep -q X/S; } &&\n> test_must_be_empty err &&\n> test_match_signal 13 \"$(cat status)\"\n> '\n> \n> With the pipe-stuffing workaround the test runs successfully.\n\nSadly this isn't enough. The pipe-stuffing solves the race with grep\n_starting_ (and thus the extra \"sleep\"), but the fundamental race we've\nseen in practice still remains. See my reply the v1 thread for details.\n\n-Peff\n"},{"id":"510055","messageId":"Z3zqKSx8NVK-QQNL@pks.im","threadId":"62731","inReplyTo":"20250107023904.GB2363@coredump.intra.peff.net","subject":"Re: [PATCH 02/10] t7422: fix flaky test caused by buffered stdout","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-07T08:47:43Z","receivedAt":"2025-01-07T08:47:48Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Mon, Jan 06, 2025 at 09:39:04PM -0500, Jeff King wrote:\n> So I don't really see a way to do this robustly.\n\nI think I found a way, which goes back to the inital idea of just\ngenerating heaps of submodules. My current version generates a submodule\n\"A\" with a couple of recursive submodules followed by 2.5k additional\nsubmodules, which overall generates ~150kB of data. This can be done\nsomewhat efficiently via git-hash-object-object(1) and git-mktree(1),\nand things work with a sleep before and after the call to grep(1).\n\nI'm a bit torn though. The required setup is quite complex, and I wonder\nwhether it is really worth it just to test this edge case. On the other\nhand it is there to cover a recent fix in 082caf527e (submodule status:\npropagate SIGPIPE, 2024-09-20), so losing the test coverage isn't all\nthat great, either. And keeping the race is not an option to me, either.\n\nSo I'm inclined to go with the below version. WDYT?\n\nPatrick\n\n\ndiff --git a/t/t7422-submodule-output.sh b/t/t7422-submodule-output.sh\nindex f21e920367..fbfc60936c 100755\n--- a/t/t7422-submodule-output.sh\n+++ b/t/t7422-submodule-output.sh\n@@ -167,10 +167,38 @@ do\n done\n \n test_expect_success !MINGW 'git submodule status --recursive propagates SIGPIPE' '\n-\t{ git submodule status --recursive 2>err; echo $?>status; } |\n-\t\tgrep -q X/S &&\n-\ttest_must_be_empty err &&\n-\ttest_match_signal 13 \"$(cat status)\"\n+\ttest_when_finished \"rm -rf repo\" &&\n+\tgit init repo &&\n+\t(\n+\t\tcd repo &&\n+\t\ttest_commit initial &&\n+\t\tgit clone . subrepo &&\n+\n+\t\tCOMMIT=$(git rev-parse HEAD) &&\n+\t\tfor i in $(test_seq 2500)\n+\t\tdo\n+\t\t\tprintf \"[submodule \\\"sm-$i\\\"]\\npath = submodule-path-$i\\n\" \"$i\" ||\n+\t\t\treturn 1\n+\t\tdone >gitmodules &&\n+\t\tBLOB=$(git hash-object -w --stdin tree &&\n+\t\tfor i in $(test_seq 2500)\n+\t\tdo\n+\t\t\tprintf \"160000 commit $COMMIT\\tsubmodule-path-%d\\n\" \"$i\" ||\n+\t\t\treturn 1\n+\t\tdone >>tree &&\n+\t\tTREE=$(git mktree err; echo $?>status; } |\n+\t\t\t{ sleep 1 && grep -q A/S && sleep 1; } &&\n+\t\ttest_must_be_empty err &&\n+\t\ttest_match_signal 13 \"$(cat status)\"\n+\t)\n '\n \n test_done\n\n"},{"id":"510056","messageId":"Z3zqvn82UJIxA9yW@pks.im","threadId":"62731","inReplyTo":"Z3zqKSx8NVK-QQNL@pks.im","subject":"Re: [PATCH 02/10] t7422: fix flaky test caused by buffered stdout","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-07T08:50:06Z","receivedAt":"2025-01-07T08:50:10Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Tue, Jan 07, 2025 at 09:47:44AM +0100, Patrick Steinhardt wrote:\n> On Mon, Jan 06, 2025 at 09:39:04PM -0500, Jeff King wrote:\n> > So I don't really see a way to do this robustly.\n> \n> I think I found a way, which goes back to the inital idea of just\n> generating heaps of submodules. My current version generates a submodule\n> \"A\" with a couple of recursive submodules followed by 2.5k additional\n> submodules, which overall generates ~150kB of data. This can be done\n> somewhat efficiently via git-hash-object-object(1) and git-mktree(1),\n> and things work with a sleep before and after the call to grep(1).\n> \n> I'm a bit torn though. The required setup is quite complex, and I wonder\n> whether it is really worth it just to test this edge case. On the other\n> hand it is there to cover a recent fix in 082caf527e (submodule status:\n> propagate SIGPIPE, 2024-09-20), so losing the test coverage isn't all\n> that great, either. And keeping the race is not an option to me, either.\n> \n> So I'm inclined to go with the below version. WDYT?\n\nGah, this of course needs to be adapted so that it is the submodule that\ncontains 2.5k recursive submodules. But the idea would still work.\n\nPatrick\n"},{"id":"510090","messageId":"xmqqr05evcht.fsf@gitster.g","threadId":"62731","inReplyTo":"20250107024829.GC2363@coredump.intra.peff.net","subject":"Re: [PATCH 02/10] t7422: fix flaky test caused by buffered stdout","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-07T16:02:06Z","receivedAt":"2025-01-07T16:02:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> So I think a simpler and more robust version is just this:\n>\n> {\n> \t{ yes || true; } &&\n> \tcommand_expecting_sigpipe; echo $? >status\n> } | true\n>\n> We'll keep producing data in \"yes\" until the pipe is closed. So it will\n> closed before command_expecting_sigpipe even starts, and there is no\n> race there. And because we're using \"true\" on the right-hand side of the\n> pipe, nothing is read at all from the pipe. So there's no guessing about\n> how much might have been read.\n\n;-)\n\n> Like I said, this won't help our current situation, but after having\n> spent a little time on it (before realizing that) I figured it was worth\n> documenting.\n\nIt is always fun to ses these clever hacks on the list.\n\nThanks.\n"},{"id":"510216","messageId":"20250109071707.GA2735258@coredump.intra.peff.net","threadId":"62731","inReplyTo":"Z3zqKSx8NVK-QQNL@pks.im","subject":"Re: [PATCH 02/10] t7422: fix flaky test caused by buffered stdout","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-01-09T07:17:07Z","receivedAt":"2025-01-09T07:17:16Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 07, 2025 at 09:47:43AM +0100, Patrick Steinhardt wrote:\n\n> On Mon, Jan 06, 2025 at 09:39:04PM -0500, Jeff King wrote:\n> > So I don't really see a way to do this robustly.\n> \n> I think I found a way, which goes back to the inital idea of just\n> generating heaps of submodules. My current version generates a submodule\n> \"A\" with a couple of recursive submodules followed by 2.5k additional\n> submodules, which overall generates ~150kB of data. This can be done\n> somewhat efficiently via git-hash-object-object(1) and git-mktree(1),\n> and things work with a sleep before and after the call to grep(1).\n\nAh, of course. I was so lost in trying to find hacks that I forgot we\ncould just actually convince it to send a lot of data. ;)\n\nYour solution looks nice. It's O(1) processes, since all of the heavy\nlifting is done by the long gitmodules file and tree.\n\nI was going to suggest that you could reduce the number of submodules by\ngiving them large paths (or large checked-out branch names) to get more\nbytes of output per submodule. But there is not really much point. What\nyou have should run quite quickly.\n\n> I'm a bit torn though. The required setup is quite complex, and I wonder\n> whether it is really worth it just to test this edge case. On the other\n> hand it is there to cover a recent fix in 082caf527e (submodule status:\n> propagate SIGPIPE, 2024-09-20), so losing the test coverage isn't all\n> that great, either. And keeping the race is not an option to me, either.\n> \n> So I'm inclined to go with the below version. WDYT?\n\nYeah, I was tempted after my last email to suggest just ditching the\ntest, too. :) But I think what you've written here is a good approach.\nI'll look carefully over what you sent in the v3 series.\n\n-Peff\n"},{"id":"510261","messageId":"xmqqikqoj72u.fsf@gitster.g","threadId":"62731","inReplyTo":"20250109071707.GA2735258@coredump.intra.peff.net","subject":"Re: [PATCH 02/10] t7422: fix flaky test caused by buffered stdout","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-09T16:16:41Z","receivedAt":"2025-01-09T16:16:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Tue, Jan 07, 2025 at 09:47:43AM +0100, Patrick Steinhardt wrote:\n>\n>> On Mon, Jan 06, 2025 at 09:39:04PM -0500, Jeff King wrote:\n>> > So I don't really see a way to do this robustly.\n>> \n>> I think I found a way, which goes back to the inital idea of just\n>> generating heaps of submodules.\n>> ...\n> Your solution looks nice. It's O(1) processes, since all of the heavy\n> lifting is done by the long gitmodules file and tree.\n>\n> I was going to suggest that you could reduce the number of submodules by\n> giving them large paths (or large checked-out branch names) to get more\n> bytes of output per submodule. But there is not really much point. What\n> you have should run quite quickly.\n\n;-)\n\n>> I'm a bit torn though. The required setup is quite complex, and I wonder\n>> whether it is really worth it just to test this edge case. On the other\n>> hand it is there to cover a recent fix in 082caf527e (submodule status:\n>> propagate SIGPIPE, 2024-09-20), so losing the test coverage isn't all\n>> that great, either. And keeping the race is not an option to me, either.\n>> \n>> So I'm inclined to go with the below version. WDYT?\n>\n> Yeah, I was tempted after my last email to suggest just ditching the\n> test, too. :) But I think what you've written here is a good approach.\n> I'll look carefully over what you sent in the v3 series.\n\nYeah. Thanks, both.\n"},{"id":"510294","messageId":"20250110-b4-pks-ci-fixes-v4-0-6e4613446080@pks.im","threadId":"62731","inReplyTo":"20250103-b4-pks-ci-fixes-v1-0-a9bb95dff833@pks.im","subject":"[PATCH v4 00/10] A couple of CI improvements","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-10T11:31:56Z","receivedAt":"2025-01-10T11:32:03Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Hi,\n\nthis patch series addresses a couple of issues I've found while\ninvestigating flaky CI jobs. Besides two more fixes for flaky jobs it\nalso removes some stale code and simplifies the setup on GitHub Actions\nto always use containerized jobs on Linux.\n\nTest runs can be found for GitLab [1] and GitHub [2].\n\nChanges in v2:\n\n - Expand a bit on the reasoning behind the conversion to use\n containerized jobs.\n - Fix commit message typo.\n - Properly fix the race in t7422 via pipe stuffing, as proposed by\n Peff.\n - Link to v1: https://lore.kernel.org/r/20250103-b4-pks-ci-fixes-v1-0-a9bb95dff833@pks.im\n\nChanges in v3:\n\n - Another iteration on the SIGPIPE test, which should now finally plug\n the race.\n - Link to v2: https://lore.kernel.org/r/20250106-b4-pks-ci-fixes-v2-0-06ae540771b7@pks.im\n\nChanges in v4:\n\n - Improve the commit message of the SIGPIPE test commit to more\n accurately describe the race.\n - Link to v3: https://lore.kernel.org/r/20250107-b4-pks-ci-fixes-v3-0-546a0ebc8481@pks.im\n\nThanks!\n\nPatrick\n\n[1]: https://gitlab.com/gitlab-org/git/-/merge_requests/277\n[2]: https://github.com/git/git/pull/1865\n\n---\nPatrick Steinhardt (10):\n t0060: fix EBUSY in MinGW when setting up runtime prefix\n t7422: fix flaky test caused by buffered stdout\n github: adapt containerized jobs to be rootless\n github: convert all Linux jobs to be containerized\n github: simplify computation of the job's distro\n gitlab-ci: remove the \"linux-old\" job\n gitlab-ci: add linux32 job testing against i386\n ci: stop special-casing for Ubuntu 16.04\n ci: use latest Ubuntu release\n ci: remove stale code for Azure Pipelines\n\n .github/workflows/main.yml | 78 ++++++++++++++++++++++-----------------------\n .gitlab-ci.yml | 19 ++++++-----\n ci/install-dependencies.sh | 6 ++--\n ci/lib.sh | 34 +++-----------------\n ci/print-test-failures.sh | 5 ---\n t/t0060-path-utils.sh | 10 +++---\n t/t7422-submodule-output.sh | 43 ++++++++++++++++++++++---\n 7 files changed, 100 insertions(+), 95 deletions(-)\n\nRange-diff versus v3:\n\n 1: 324b174988 = 1: ca4dc636aa t0060: fix EBUSY in MinGW when setting up runtime prefix\n 2: cc095aa2b1 ! 2: d41c00feb1 t7422: fix flaky test caused by buffered stdout\n @@ Commit message\n error: last command exited with $?=1\n not ok 18 - git submodule status --recursive propagates SIGPIPE\n \n - The issue is caused by us using grep(1) to terminate the pipe on the\n - first matching line in the recursing git-submodule(1) process. Standard\n - streams are typically buffered though, so this condition is racy and may\n - cause us to terminate the pipe after git-submodule(1) has already\n - exited, and in that case we wouldn't see the expected signal.\n + The issue is caused by a race between git-submodule(1) and grep(1):\n +\n + 1. git-submodule(1) (or its child process) writes the first X/S line\n + we're trying to match.\n +\n + 2. grep(1) matches the line.\n +\n + 3a. grep(1) exits, closing the pipe.\n +\n + 3b. git-submodule(1) (or its child process) writes the rest of its\n + lines.\n +\n + Steps 3a and 3b happen at the same time without any guarantees. If 3a\n + happens first, we get SIGPIPE. Otherwise, we don't and the test fails.\n \n Fix the issue by generating a couple thousand nested submodules and\n matching on the first nested submodule. This ensures that the recursive\n git-submodule(1) process completely fills its stdout buffer, which makes\n subsequent writes block until the downstream consumer of the pipe either\n - fully drains it or closes it.\n + reads more or closes it.\n \n To verify that this works as expected one can apply the following patch\n to the preimage of this commit, which used to reliably trigger the race:\n 3: 73c98e7628 = 3: 6593e3307c github: adapt containerized jobs to be rootless\n 4: 4d8f2bdce7 = 4: 9997698c6e github: convert all Linux jobs to be containerized\n 5: 4a987aa42e = 5: 65797c51dc github: simplify computation of the job's distro\n 6: bd44700668 = 6: 687ae0c3f2 gitlab-ci: remove the \"linux-old\" job\n 7: e095c6757c = 7: 974229776b gitlab-ci: add linux32 job testing against i386\n 8: f885740877 = 8: 112ea61a6b ci: stop special-casing for Ubuntu 16.04\n 9: 17b19dc51e = 9: 465cd85898 ci: use latest Ubuntu release\n10: 95ce4406c7 = 10: d671ee1f7f ci: remove stale code for Azure Pipelines\n\n---\nbase-commit: 1b4e9a5f8b5f048972c21fe8acafe0404096f694\nchange-id: 20250103-b4-pks-ci-fixes-2d0a23fb5c78\n\n"},{"id":"510295","messageId":"20250110-b4-pks-ci-fixes-v4-1-6e4613446080@pks.im","threadId":"62731","inReplyTo":"20250110-b4-pks-ci-fixes-v4-0-6e4613446080@pks.im","subject":"[PATCH v4 01/10] t0060: fix EBUSY in MinGW when setting up runtime prefix","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-10T11:31:57Z","receivedAt":"2025-01-10T11:32:04Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Two of our tests in t0060 verify that the runtime prefix functionality\nworks as expected by creating a separate directory hierarchy, copying\nthe Git executable in there and then creating scripts relative to that\nexecutable.\n\nThese tests fail quite regularly in GitLab CI with the following error:\n\n expecting success of 0060.218 '%(prefix)/ works':\n mkdir -p pretend/bin &&\n cp \"$GIT_EXEC_PATH\"/git$X pretend/bin/ &&\n git config yes.path \"%(prefix)/yes\" &&\n GIT_EXEC_PATH= ./pretend/bin/git config --path yes.path >actual &&\n echo \"$(pwd)/pretend/yes\" >expect &&\n test_cmp expect actual\n ++ mkdir -p pretend/bin\n ++ cp /c/GitLab-Runner/builds/gitlab-org/git/git.exe pretend/bin/\n cp: cannot create regular file 'pretend/bin/git.exe': Device or resource busy\n error: last command exited with $?=1\n not ok 218 - %(prefix)/ works\n\nSeemingly, the \"git.exe\" binary we are trying to overwrite is still\nbeing held open. It is somewhat puzzling why exactly that is: while the\npreceding test _does_ write to and execute the same path, it should have\nexited and shouldn't keep any backgrounded processes around. So it must\nbe held open by something else, either in MinGW or in Windows itself.\n\nWhile the root cause is puzzling, the workaround is trivial enough:\ninstead of writing the file twice we simply pull the common setup into a\nseparate test case so that we won't observe EBUSY in the first place.\n\nSigned-off-by: Patrick Steinhardt \n---\n t/t0060-path-utils.sh | 10 ++++++----\n 1 file changed, 6 insertions(+), 4 deletions(-)\n\ndiff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh\nindex dbb2e73bcd912ae6a804603ff54e4c609966fa5d..8545cdfab559b4e247cb2699965e637529fd930a 100755\n--- a/t/t0060-path-utils.sh\n+++ b/t/t0060-path-utils.sh\n@@ -592,17 +592,19 @@ test_lazy_prereq CAN_EXEC_IN_PWD '\n \t./git rev-parse\n '\n \n+test_expect_success !VALGRIND,RUNTIME_PREFIX,CAN_EXEC_IN_PWD 'setup runtime prefix' '\n+\tmkdir -p pretend/bin &&\n+\tcp \"$GIT_EXEC_PATH\"/git$X pretend/bin/\n+'\n+\n test_expect_success !VALGRIND,RUNTIME_PREFIX,CAN_EXEC_IN_PWD 'RUNTIME_PREFIX works' '\n-\tmkdir -p pretend/bin pretend/libexec/git-core &&\n+\tmkdir -p pretend/libexec/git-core &&\n \techo \"echo HERE\" | write_script pretend/libexec/git-core/git-here &&\n-\tcp \"$GIT_EXEC_PATH\"/git$X pretend/bin/ &&\n \tGIT_EXEC_PATH= ./pretend/bin/git here >actual &&\n \techo HERE >expect &&\n \ttest_cmp expect actual'\n \n test_expect_success !VALGRIND,RUNTIME_PREFIX,CAN_EXEC_IN_PWD '%(prefix)/ works' '\n-\tmkdir -p pretend/bin &&\n-\tcp \"$GIT_EXEC_PATH\"/git$X pretend/bin/ &&\n \tgit config yes.path \"%(prefix)/yes\" &&\n \tGIT_EXEC_PATH= ./pretend/bin/git config --path yes.path >actual &&\n \techo \"$(pwd)/pretend/yes\" >expect &&\n\n-- \n2.48.0.rc2.279.g1de40edade.dirty\n\n"},{"id":"510296","messageId":"20250110-b4-pks-ci-fixes-v4-2-6e4613446080@pks.im","threadId":"62731","inReplyTo":"20250110-b4-pks-ci-fixes-v4-0-6e4613446080@pks.im","subject":"[PATCH v4 02/10] t7422: fix flaky test caused by buffered stdout","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-10T11:31:58Z","receivedAt":"2025-01-10T11:32:05Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"One test in t7422 asserts that `git submodule status --recursive`\nproperly handles SIGPIPE. This test is flaky though and may sometimes\nnot see a SIGPIPE at all:\n\n expecting success of 7422.18 'git submodule status --recursive propagates SIGPIPE':\n { git submodule status --recursive 2>err; echo $?>status; } |\n grep -q X/S &&\n test_must_be_empty err &&\n test_match_signal 13 \"$(cat status)\"\n ++ git submodule status --recursive\n ++ grep -q X/S\n ++ echo 0\n ++ test_must_be_empty err\n ++ test 1 -ne 1\n ++ test_path_is_file err\n ++ test 1 -ne 1\n ++ test -f err\n ++ test -s err\n +++ cat status\n ++ test_match_signal 13 0\n ++ test 0 = 141\n ++ test 0 = 269\n ++ return 1\n error: last command exited with $?=1\n not ok 18 - git submodule status --recursive propagates SIGPIPE\n\nThe issue is caused by a race between git-submodule(1) and grep(1):\n\n 1. git-submodule(1) (or its child process) writes the first X/S line\n we're trying to match.\n\n 2. grep(1) matches the line.\n\n 3a. grep(1) exits, closing the pipe.\n\n 3b. git-submodule(1) (or its child process) writes the rest of its\n lines.\n\nSteps 3a and 3b happen at the same time without any guarantees. If 3a\nhappens first, we get SIGPIPE. Otherwise, we don't and the test fails.\n\nFix the issue by generating a couple thousand nested submodules and\nmatching on the first nested submodule. This ensures that the recursive\ngit-submodule(1) process completely fills its stdout buffer, which makes\nsubsequent writes block until the downstream consumer of the pipe either\nreads more or closes it.\n\nTo verify that this works as expected one can apply the following patch\nto the preimage of this commit, which used to reliably trigger the race:\n\n diff --git a/t/t7422-submodule-output.sh b/t/t7422-submodule-output.sh\n index 3c5177cc30..df6001f8a0 100755\n --- a/t/t7422-submodule-output.sh\n +++ b/t/t7422-submodule-output.sh\n @@ -202,7 +202,7 @@ test_expect_success !MINGW 'git submodule status --recursive propagates SIGPIPE'\n \t\tcd repo &&\n \t\tGIT_ALLOW_PROTOCOL=file git submodule add \"$(pwd)\"/../submodule &&\n \t\t{ git submodule status --recursive 2>err; echo $?>status; } |\n -\t\t\tgrep -q recursive-submodule-path-1 &&\n +\t\t\t{ sleep 1 && grep -q recursive-submodule-path-1 && sleep 1; } &&\n \t\ttest_must_be_empty err &&\n \t\ttest_match_signal 13 \"$(cat status)\"\n \t)\n\nWith the pipe-stuffing workaround the test runs successfully.\n\nHelped-by: Jeff King \nSigned-off-by: Patrick Steinhardt \n---\n t/t7422-submodule-output.sh | 43 +++++++++++++++++++++++++++++++++++++++----\n 1 file changed, 39 insertions(+), 4 deletions(-)\n\ndiff --git a/t/t7422-submodule-output.sh b/t/t7422-submodule-output.sh\nindex f21e9203678b94701281d5339ae8bfe53d5de0ed..023a5cbdc44bac2389fca45cf7017750627c4ce9 100755\n--- a/t/t7422-submodule-output.sh\n+++ b/t/t7422-submodule-output.sh\n@@ -167,10 +167,45 @@ do\n done\n \n test_expect_success !MINGW 'git submodule status --recursive propagates SIGPIPE' '\n-\t{ git submodule status --recursive 2>err; echo $?>status; } |\n-\t\tgrep -q X/S &&\n-\ttest_must_be_empty err &&\n-\ttest_match_signal 13 \"$(cat status)\"\n+\t# The test setup is somewhat involved because triggering a SIGPIPE is\n+\t# racy with buffered pipes. To avoid the raciness we thus need to make\n+\t# sure that the subprocess in question fills the buffers completely,\n+\t# which requires a couple thousand submodules in total.\n+\ttest_when_finished \"rm -rf submodule repo\" &&\n+\tgit init submodule &&\n+\t(\n+\t\tcd submodule &&\n+\t\ttest_commit initial &&\n+\n+\t\tCOMMIT=$(git rev-parse HEAD) &&\n+\t\tfor i in $(test_seq 2000)\n+\t\tdo\n+\t\t\tprintf \"[submodule \\\"sm-$i\\\"]\\npath = recursive-submodule-path-$i\\n\" \"$i\" ||\n+\t\t\treturn 1\n+\t\tdone >gitmodules &&\n+\t\tBLOB=$(git hash-object -w --stdin tree &&\n+\t\tfor i in $(test_seq 2000)\n+\t\tdo\n+\t\t\tprintf \"160000 commit $COMMIT\\trecursive-submodule-path-%d\\n\" \"$i\" ||\n+\t\t\treturn 1\n+\t\tdone >>tree &&\n+\t\tTREE=$(git mktree err; echo $?>status; } |\n+\t\t\tgrep -q recursive-submodule-path-1 &&\n+\t\ttest_must_be_empty err &&\n+\t\ttest_match_signal 13 \"$(cat status)\"\n+\t)\n '\n \n test_done\n\n-- \n2.48.0.rc2.279.g1de40edade.dirty\n\n"},{"id":"510297","messageId":"20250110-b4-pks-ci-fixes-v4-4-6e4613446080@pks.im","threadId":"62731","inReplyTo":"20250110-b4-pks-ci-fixes-v4-0-6e4613446080@pks.im","subject":"[PATCH v4 04/10] github: convert all Linux jobs to be containerized","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-10T11:32:00Z","receivedAt":"2025-01-10T11:32:06Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"We have split the CI jobs in GitHub Workflows into two categories:\n\n - Those running on a machine pool directly.\n\n - Those running in a container on the machine pool.\n\nThe latter is more flexible because it allows us to freely pick whatever\ncontainer image we want to use for a specific job, while the former only\nallows us to pick from a handful of different distros. The containerized\njobs do not have any significant downsides to the best of my knowledge:\n\n - They aren't significantly slower to start up. A quick comparison by\n Peff shows that the difference is mostly lost in the noise:\n\n job | old | new\n --------------------|------|------\n linux-TEST-vars 11m30s 10m54s\n linux-asan-ubsan 30m26s 31m14s\n linux-gcc 9m47s 10m6s\n linux-gcc-default 9m47s 9m41s\n linux-leaks 25m50s 25m21s\n linux-meson 10m36s 10m41s\n linux-reftable 10m25s 10m23s\n linux-reftable-leaks 27m18s 27m28s\n linux-sha256 9m54s 10m31s\n\n Some jobs are a bit faster, some are a bit slower, but there does\n not seem to be any significant change.\n\n - Containerized jobs run as root, which keeps a couple of tests from\n running. This has been addressed in the preceding commit though,\n where we now use setpriv(1) to run tests as a separate user.\n\n - GitHub injects a Node binary into containerized jobs, which is\n dynamically linked. This has led to some issues in the past [1], but\n only for our 32 bit jobs. The issues have since been resolved.\n\nOverall there seem to be no downsides, but the upside is that we have\nmore control over the exact image that these jobs use. Convert the Linux\njobs accordingly.\n\n[1]: https://lore.kernel.org/git/20240912094841.GD589828@coredump.intra.peff.net/\n\nSigned-off-by: Patrick Steinhardt \n---\n .github/workflows/main.yml | 68 ++++++++++++++++++++++++++--------------------\n 1 file changed, 39 insertions(+), 29 deletions(-)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex b02f5873a540b458d38e7951b4ee3d5ca598ae23..8e5847da4fab009ad699c18e1a5a336a8b45c3ed 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -259,20 +259,6 @@ jobs:\n fail-fast: false\n matrix:\n vector:\n- - jobname: linux-sha256\n- cc: clang\n- pool: ubuntu-latest\n- - jobname: linux-reftable\n- cc: clang\n- pool: ubuntu-latest\n- - jobname: linux-gcc\n- cc: gcc\n- cc_package: gcc-8\n- pool: ubuntu-20.04\n- - jobname: linux-TEST-vars\n- cc: gcc\n- cc_package: gcc-8\n- pool: ubuntu-20.04\n - jobname: osx-clang\n cc: clang\n pool: macos-13\n@@ -285,21 +271,6 @@ jobs:\n - jobname: osx-meson\n cc: clang\n pool: macos-13\n- - jobname: linux-gcc-default\n- cc: gcc\n- pool: ubuntu-latest\n- - jobname: linux-leaks\n- cc: gcc\n- pool: ubuntu-latest\n- - jobname: linux-reftable-leaks\n- cc: gcc\n- pool: ubuntu-latest\n- - jobname: linux-asan-ubsan\n- cc: clang\n- pool: ubuntu-latest\n- - jobname: linux-meson\n- cc: gcc\n- pool: ubuntu-latest\n env:\n CC: ${{matrix.vector.cc}}\n CC_PACKAGE: ${{matrix.vector.cc_package}}\n@@ -342,6 +313,44 @@ jobs:\n fail-fast: false\n matrix:\n vector:\n+ - jobname: linux-sha256\n+ image: ubuntu:latest\n+ cc: clang\n+ distro: ubuntu-latest\n+ - jobname: linux-reftable\n+ image: ubuntu:latest\n+ cc: clang\n+ distro: ubuntu-latest\n+ - jobname: linux-gcc\n+ image: ubuntu:20.04\n+ cc: gcc\n+ cc_package: gcc-8\n+ distro: ubuntu-20.04\n+ - jobname: linux-TEST-vars\n+ image: ubuntu:20.04\n+ cc: gcc\n+ cc_package: gcc-8\n+ distro: ubuntu-20.04\n+ - jobname: linux-gcc-default\n+ image: ubuntu:latest\n+ cc: gcc\n+ distro: ubuntu-latest\n+ - jobname: linux-leaks\n+ image: ubuntu:latest\n+ cc: gcc\n+ distro: ubuntu-latest\n+ - jobname: linux-reftable-leaks\n+ image: ubuntu:latest\n+ cc: gcc\n+ distro: ubuntu-latest\n+ - jobname: linux-asan-ubsan\n+ image: ubuntu:latest\n+ cc: clang\n+ distro: ubuntu-latest\n+ - jobname: linux-meson\n+ image: ubuntu:latest\n+ cc: gcc\n+ distro: ubuntu-latest\n - jobname: linux-musl\n image: alpine\n distro: alpine-latest\n@@ -363,6 +372,7 @@ jobs:\n env:\n jobname: ${{matrix.vector.jobname}}\n distro: ${{matrix.vector.distro}}\n+ CC: ${{matrix.vector.cc}}\n runs-on: ubuntu-latest\n container: ${{matrix.vector.image}}\n steps:\n\n-- \n2.48.0.rc2.279.g1de40edade.dirty\n\n"},{"id":"510298","messageId":"20250110-b4-pks-ci-fixes-v4-3-6e4613446080@pks.im","threadId":"62731","inReplyTo":"20250110-b4-pks-ci-fixes-v4-0-6e4613446080@pks.im","subject":"[PATCH v4 03/10] github: adapt containerized jobs to be rootless","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-10T11:31:59Z","receivedAt":"2025-01-10T11:32:06Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"The containerized jobs in GitHub Actions run as root, giving them\nspecial permissions to for example delete files even when the user\nshouldn't be able to due to file permissions. This limitation keeps us\nfrom using containerized jobs for most of our Ubuntu-based jobs as it\ncauses a number of tests to fail.\n\nAdapt the jobs to create a separate user that executes the test suite.\nThis follows similar infrastructure that we already have in GitLab CI.\n\nSigned-off-by: Patrick Steinhardt \n---\n .github/workflows/main.yml | 6 ++++--\n ci/install-dependencies.sh | 2 +-\n 2 files changed, 5 insertions(+), 3 deletions(-)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex 900be9957a23fcaa64e1aefd0c8638c5f84b7997..b02f5873a540b458d38e7951b4ee3d5ca598ae23 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -371,10 +371,12 @@ jobs:\n run: apt -q update && apt -q -y install libc6-amd64 lib64stdc++6\n - uses: actions/checkout@v4\n - run: ci/install-dependencies.sh\n- - run: ci/run-build-and-tests.sh\n+ - run: useradd builder --create-home\n+ - run: chown -R builder .\n+ - run: sudo --preserve-env --set-home --user=builder ci/run-build-and-tests.sh\n - name: print test failures\n if: failure() && env.FAILED_TEST_ARTIFACTS != ''\n- run: ci/print-test-failures.sh\n+ run: sudo --preserve-env --set-home --user=builder ci/print-test-failures.sh\n - name: Upload failed tests' directories\n if: failure() && env.FAILED_TEST_ARTIFACTS != ''\n uses: actions/upload-artifact@v4\ndiff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh\nindex d1cb9fa8785388b3674fcea4dd682abc0725c968..ecb5b9d36c20d3e7e96148ac628a96c62642c308 100755\n--- a/ci/install-dependencies.sh\n+++ b/ci/install-dependencies.sh\n@@ -31,7 +31,7 @@ alpine-*)\n \t;;\n fedora-*|almalinux-*)\n \tdnf -yq update >/dev/null &&\n-\tdnf -yq install make gcc findutils diffutils perl python3 gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null\n+\tdnf -yq install shadow-utils sudo make gcc findutils diffutils perl python3 gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null\n \t;;\n ubuntu-*|ubuntu32-*|debian-*)\n \t# Required so that apt doesn't wait for user input on certain packages.\n\n-- \n2.48.0.rc2.279.g1de40edade.dirty\n\n"},{"id":"510299","messageId":"20250110-b4-pks-ci-fixes-v4-5-6e4613446080@pks.im","threadId":"62731","inReplyTo":"20250110-b4-pks-ci-fixes-v4-0-6e4613446080@pks.im","subject":"[PATCH v4 05/10] github: simplify computation of the job's distro","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-10T11:32:01Z","receivedAt":"2025-01-10T11:32:07Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"We explicitly list the distro of Linux-based jobs, but it is equivalent\nto the name of the image in almost all cases, except that colons are\nreplaced with dashes. Drop the redundant information and massage it in\nour CI scripts, which is equivalent to how we do it in GitLab CI.\n\nThere are a couple of exceptions:\n\n - The \"linux32\" job, whose distro name is different than the image\n name. This is handled by adapting all sites to use the new name.\n\n - The \"alpine\" and \"fedora\" jobs, neither of which specify a tag for\n their image. This is handled by adding the \"latest\" tag.\n\nSigned-off-by: Patrick Steinhardt \n---\n .github/workflows/main.yml | 22 ++++------------------\n ci/install-dependencies.sh | 4 ++--\n ci/lib.sh | 2 ++\n 3 files changed, 8 insertions(+), 20 deletions(-)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex 8e5847da4fab009ad699c18e1a5a336a8b45c3ed..b54da639a650682495994e3c7b137eab4e6cb3bf 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -275,7 +275,7 @@ jobs:\n CC: ${{matrix.vector.cc}}\n CC_PACKAGE: ${{matrix.vector.cc_package}}\n jobname: ${{matrix.vector.jobname}}\n- distro: ${{matrix.vector.pool}}\n+ CI_JOB_IMAGE: ${{matrix.vector.pool}}\n TEST_OUTPUT_DIRECTORY: ${{github.workspace}}/t\n runs-on: ${{matrix.vector.pool}}\n steps:\n@@ -316,63 +316,49 @@ jobs:\n - jobname: linux-sha256\n image: ubuntu:latest\n cc: clang\n- distro: ubuntu-latest\n - jobname: linux-reftable\n image: ubuntu:latest\n cc: clang\n- distro: ubuntu-latest\n - jobname: linux-gcc\n image: ubuntu:20.04\n cc: gcc\n cc_package: gcc-8\n- distro: ubuntu-20.04\n - jobname: linux-TEST-vars\n image: ubuntu:20.04\n cc: gcc\n cc_package: gcc-8\n- distro: ubuntu-20.04\n - jobname: linux-gcc-default\n image: ubuntu:latest\n cc: gcc\n- distro: ubuntu-latest\n - jobname: linux-leaks\n image: ubuntu:latest\n cc: gcc\n- distro: ubuntu-latest\n - jobname: linux-reftable-leaks\n image: ubuntu:latest\n cc: gcc\n- distro: ubuntu-latest\n - jobname: linux-asan-ubsan\n image: ubuntu:latest\n cc: clang\n- distro: ubuntu-latest\n - jobname: linux-meson\n image: ubuntu:latest\n cc: gcc\n- distro: ubuntu-latest\n - jobname: linux-musl\n- image: alpine\n- distro: alpine-latest\n+ image: alpine:latest\n # Supported until 2025-04-02.\n - jobname: linux32\n image: i386/ubuntu:focal\n- distro: ubuntu32-20.04\n - jobname: pedantic\n- image: fedora\n- distro: fedora-latest\n+ image: fedora:latest\n # A RHEL 8 compatible distro. Supported until 2029-05-31.\n - jobname: almalinux-8\n image: almalinux:8\n- distro: almalinux-8\n # Supported until 2026-08-31.\n - jobname: debian-11\n image: debian:11\n- distro: debian-11\n env:\n jobname: ${{matrix.vector.jobname}}\n- distro: ${{matrix.vector.distro}}\n CC: ${{matrix.vector.cc}}\n+ CI_JOB_IMAGE: ${{matrix.vector.image}}\n runs-on: ubuntu-latest\n container: ${{matrix.vector.image}}\n steps:\ndiff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh\nindex ecb5b9d36c20d3e7e96148ac628a96c62642c308..d5a959e25ff3236656ff3416b81732ec5c2107c1 100755\n--- a/ci/install-dependencies.sh\n+++ b/ci/install-dependencies.sh\n@@ -33,7 +33,7 @@ fedora-*|almalinux-*)\n \tdnf -yq update >/dev/null &&\n \tdnf -yq install shadow-utils sudo make gcc findutils diffutils perl python3 gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null\n \t;;\n-ubuntu-*|ubuntu32-*|debian-*)\n+ubuntu-*|i386/ubuntu-*|debian-*)\n \t# Required so that apt doesn't wait for user input on certain packages.\n \texport DEBIAN_FRONTEND=noninteractive\n \n@@ -42,7 +42,7 @@ ubuntu-*|ubuntu32-*|debian-*)\n \t\tSVN='libsvn-perl subversion'\n \t\tLANGUAGES='language-pack-is'\n \t\t;;\n-\tubuntu32-*)\n+\ti386/ubuntu-*)\n \t\tSVN=\n \t\tLANGUAGES='language-pack-is'\n \t\t;;\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex 8885ee3c3f86c62e8783d27756b8779bd491e7e6..f8b68ab8a6546802756fd516ca15a2c97223da5f 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -246,6 +246,8 @@ then\n \n \tGIT_TEST_OPTS=\"--github-workflow-markup\"\n \tJOBS=10\n+\n+\tdistro=$(echo \"$CI_JOB_IMAGE\" | tr : -)\n elif test true = \"$GITLAB_CI\"\n then\n \tCI_TYPE=gitlab-ci\n\n-- \n2.48.0.rc2.279.g1de40edade.dirty\n\n"},{"id":"510300","messageId":"20250110-b4-pks-ci-fixes-v4-6-6e4613446080@pks.im","threadId":"62731","inReplyTo":"20250110-b4-pks-ci-fixes-v4-0-6e4613446080@pks.im","subject":"[PATCH v4 06/10] gitlab-ci: remove the \"linux-old\" job","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-10T11:32:02Z","receivedAt":"2025-01-10T11:32:07Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"The \"linux-old\" job was historically testing against the oldest\nsupported LTS release of Ubuntu. But with c85bcb5de1 (gitlab-ci: switch\nfrom Ubuntu 16.04 to 20.04, 2024-10-31) it has been converted to test\nagainst Ubuntu 20.04, which already gets exercised in a couple of other\nCI jobs. It's thus not adding any significant test coverage.\n\nDrop the job.\n\nSigned-off-by: Patrick Steinhardt \n---\n .gitlab-ci.yml | 3 ---\n 1 file changed, 3 deletions(-)\n\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 9254e01583306e67dc12b6b9e0015183e1108655..00bc727865031620752771af4a9030c7de1b73df 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -36,9 +36,6 @@ test:linux:\n fi\n parallel:\n matrix:\n- - jobname: linux-old\n- image: ubuntu:20.04\n- CC: gcc\n - jobname: linux-sha256\n image: ubuntu:latest\n CC: clang\n\n-- \n2.48.0.rc2.279.g1de40edade.dirty\n\n"},{"id":"510301","messageId":"20250110-b4-pks-ci-fixes-v4-7-6e4613446080@pks.im","threadId":"62731","inReplyTo":"20250110-b4-pks-ci-fixes-v4-0-6e4613446080@pks.im","subject":"[PATCH v4 07/10] gitlab-ci: add linux32 job testing against i386","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-10T11:32:03Z","receivedAt":"2025-01-10T11:32:08Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Add another job to GitLab CI that tests against the i386 architecture.\nThis job is equivalent to the same job in GitHub Workflows.\n\nSigned-off-by: Patrick Steinhardt \n---\n .gitlab-ci.yml | 2 ++\n ci/lib.sh | 2 +-\n 2 files changed, 3 insertions(+), 1 deletion(-)\n\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 00bc727865031620752771af4a9030c7de1b73df..29e9056dd5010f8843e42aeae8410973c825de54 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -66,6 +66,8 @@ test:linux:\n image: fedora:latest\n - jobname: linux-musl\n image: alpine:latest\n+ - jobname: linux32\n+ image: i386/ubuntu:20.04\n - jobname: linux-meson\n image: ubuntu:latest\n CC: gcc\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex f8b68ab8a6546802756fd516ca15a2c97223da5f..2293849ada3b45873f80e4392ab93c65657d0f13 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -269,7 +269,7 @@ then\n \t\tCI_OS_NAME=osx\n \t\tJOBS=$(nproc)\n \t\t;;\n-\t*,alpine:*|*,fedora:*|*,ubuntu:*)\n+\t*,alpine:*|*,fedora:*|*,ubuntu:*|*,i386/ubuntu:*)\n \t\tCI_OS_NAME=linux\n \t\tJOBS=$(nproc)\n \t\t;;\n\n-- \n2.48.0.rc2.279.g1de40edade.dirty\n\n"},{"id":"510302","messageId":"20250110-b4-pks-ci-fixes-v4-8-6e4613446080@pks.im","threadId":"62731","inReplyTo":"20250110-b4-pks-ci-fixes-v4-0-6e4613446080@pks.im","subject":"[PATCH v4 08/10] ci: stop special-casing for Ubuntu 16.04","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-10T11:32:04Z","receivedAt":"2025-01-10T11:32:09Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"With c85bcb5de1 (gitlab-ci: switch from Ubuntu 16.04 to 20.04,\n2024-10-31) we have adapted the last CI job to stop using Ubuntu 16.04\nin favor of Ubuntu 20.04. Remove the special-casing we still have in our\nCI scripts.\n\nSigned-off-by: Patrick Steinhardt \n---\n ci/lib.sh | 9 +--------\n 1 file changed, 1 insertion(+), 8 deletions(-)\n\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex 2293849ada3b45873f80e4392ab93c65657d0f13..77a4aabdb8fb416c1733f02d02145b6bc0849998 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -347,14 +347,7 @@ ubuntu-*)\n \tfi\n \tMAKEFLAGS=\"$MAKEFLAGS PYTHON_PATH=/usr/bin/$PYTHON_PACKAGE\"\n \n-\tcase \"$distro\" in\n-\tubuntu-16.04)\n-\t\t# Apache is too old for HTTP/2.\n-\t\t;;\n-\t*)\n-\t\texport GIT_TEST_HTTPD=true\n-\t\t;;\n-\tesac\n+\texport GIT_TEST_HTTPD=true\n \n \t# The Linux build installs the defined dependency versions below.\n \t# The OS X build installs much more recent versions, whichever\n\n-- \n2.48.0.rc2.279.g1de40edade.dirty\n\n"},{"id":"510303","messageId":"20250110-b4-pks-ci-fixes-v4-9-6e4613446080@pks.im","threadId":"62731","inReplyTo":"20250110-b4-pks-ci-fixes-v4-0-6e4613446080@pks.im","subject":"[PATCH v4 09/10] ci: use latest Ubuntu release","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-10T11:32:05Z","receivedAt":"2025-01-10T11:32:11Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Both GitHub Actions and GitLab CI use the \"ubuntu:latest\" tag as the\ndefault image for most jobs. This tag is somewhat misleading though, as\nit does not refer to the latest release of Ubuntu, but to the latest LTS\nrelease thereof. But as we already have a couple of jobs exercising the\noldest LTS release of Ubuntu that Git still supports, it would make more\nsense to test the oldest and youngest versions of Ubuntu.\n\nAdapt these jobs to instead use the \"ubuntu:rolling\" tag, which refers\nto the actual latest release, which currently is Ubuntu 24.10.\n\nSigned-off-by: Patrick Steinhardt \n---\n .github/workflows/main.yml | 14 +++++++-------\n .gitlab-ci.yml | 14 +++++++-------\n 2 files changed, 14 insertions(+), 14 deletions(-)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex b54da639a650682495994e3c7b137eab4e6cb3bf..b90381ae015edf9db5aa4b8c0ace9bb5c549c37b 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -314,10 +314,10 @@ jobs:\n matrix:\n vector:\n - jobname: linux-sha256\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n cc: clang\n - jobname: linux-reftable\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n cc: clang\n - jobname: linux-gcc\n image: ubuntu:20.04\n@@ -328,19 +328,19 @@ jobs:\n cc: gcc\n cc_package: gcc-8\n - jobname: linux-gcc-default\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n cc: gcc\n - jobname: linux-leaks\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n cc: gcc\n - jobname: linux-reftable-leaks\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n cc: gcc\n - jobname: linux-asan-ubsan\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n cc: clang\n - jobname: linux-meson\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n cc: gcc\n - jobname: linux-musl\n image: alpine:latest\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 29e9056dd5010f8843e42aeae8410973c825de54..8ed3ff5f0373d70b6f609dc5292dda2dd7fd8f88 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -37,10 +37,10 @@ test:linux:\n parallel:\n matrix:\n - jobname: linux-sha256\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n CC: clang\n - jobname: linux-reftable\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n CC: clang\n - jobname: linux-gcc\n image: ubuntu:20.04\n@@ -51,16 +51,16 @@ test:linux:\n CC: gcc\n CC_PACKAGE: gcc-8\n - jobname: linux-gcc-default\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n CC: gcc\n - jobname: linux-leaks\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n CC: gcc\n - jobname: linux-reftable-leaks\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n CC: gcc\n - jobname: linux-asan-ubsan\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n CC: clang\n - jobname: pedantic\n image: fedora:latest\n@@ -69,7 +69,7 @@ test:linux:\n - jobname: linux32\n image: i386/ubuntu:20.04\n - jobname: linux-meson\n- image: ubuntu:latest\n+ image: ubuntu:rolling\n CC: gcc\n artifacts:\n paths:\n\n-- \n2.48.0.rc2.279.g1de40edade.dirty\n\n"},{"id":"510304","messageId":"20250110-b4-pks-ci-fixes-v4-10-6e4613446080@pks.im","threadId":"62731","inReplyTo":"20250110-b4-pks-ci-fixes-v4-0-6e4613446080@pks.im","subject":"[PATCH v4 10/10] ci: remove stale code for Azure Pipelines","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-10T11:32:06Z","receivedAt":"2025-01-10T11:32:12Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Support for Azure Pipelines has been retired in 6081d3898f (ci: retire\nthe Azure Pipelines definition, 2020-04-11) in favor of GitHub Actions.\nOur CI library still has some infrastructure left for Azure though that\nis now unused. Remove it.\n\nSigned-off-by: Patrick Steinhardt \n---\n ci/lib.sh | 21 +--------------------\n ci/print-test-failures.sh | 5 -----\n 2 files changed, 1 insertion(+), 25 deletions(-)\n\ndiff --git a/ci/lib.sh b/ci/lib.sh\nindex 77a4aabdb8fb416c1733f02d02145b6bc0849998..4003354f16c048b969c0bb4340d2ee2777767300 100755\n--- a/ci/lib.sh\n+++ b/ci/lib.sh\n@@ -206,26 +206,7 @@ export TERM=${TERM:-dumb}\n # Clear MAKEFLAGS that may come from the outside world.\n export MAKEFLAGS=\n \n-if test -n \"$SYSTEM_COLLECTIONURI\" || test -n \"$SYSTEM_TASKDEFINITIONSURI\"\n-then\n-\tCI_TYPE=azure-pipelines\n-\t# We are running in Azure Pipelines\n-\tCI_BRANCH=\"$BUILD_SOURCEBRANCH\"\n-\tCI_COMMIT=\"$BUILD_SOURCEVERSION\"\n-\tCI_JOB_ID=\"$BUILD_BUILDID\"\n-\tCI_JOB_NUMBER=\"$BUILD_BUILDNUMBER\"\n-\tCI_OS_NAME=\"$(echo \"$AGENT_OS\" | tr A-Z a-z)\"\n-\ttest darwin != \"$CI_OS_NAME\" || CI_OS_NAME=osx\n-\tCI_REPO_SLUG=\"$(expr \"$BUILD_REPOSITORY_URI\" : '.*/\\([^/]*/[^/]*\\)$')\"\n-\tCC=\"${CC:-gcc}\"\n-\n-\t# use a subdirectory of the cache dir (because the file share is shared\n-\t# among *all* phases)\n-\tcache_dir=\"$HOME/test-cache/$SYSTEM_PHASENAME\"\n-\n-\tGIT_TEST_OPTS=\"--write-junit-xml\"\n-\tJOBS=10\n-elif test true = \"$GITHUB_ACTIONS\"\n+if test true = \"$GITHUB_ACTIONS\"\n then\n \tCI_TYPE=github-actions\n \tCI_BRANCH=\"$GITHUB_REF\"\ndiff --git a/ci/print-test-failures.sh b/ci/print-test-failures.sh\nindex 655687dd827e5b3e4d4879803b0d4499e7751380..dc910e51609cd7344b1ad03fdb4e820e47ad3a88 100755\n--- a/ci/print-test-failures.sh\n+++ b/ci/print-test-failures.sh\n@@ -39,11 +39,6 @@ do\n \t\ttest_name=\"${test_name##*/}\"\n \t\ttrash_dir=\"trash directory.$test_name\"\n \t\tcase \"$CI_TYPE\" in\n-\t\tazure-pipelines)\n-\t\t\tmkdir -p failed-test-artifacts\n-\t\t\tmv \"$trash_dir\" failed-test-artifacts\n-\t\t\tcontinue\n-\t\t\t;;\n \t\tgithub-actions)\n \t\t\tmkdir -p failed-test-artifacts\n \t\t\techo \"FAILED_TEST_ARTIFACTS=${TEST_OUTPUT_DIRECTORY:t}/failed-test-artifacts\" >>$GITHUB_ENV\n\n-- \n2.48.0.rc2.279.g1de40edade.dirty\n\n"},{"id":"510310","messageId":"20250110120330.GD1014503@coredump.intra.peff.net","threadId":"62731","inReplyTo":"20250110-b4-pks-ci-fixes-v4-0-6e4613446080@pks.im","subject":"Re: [PATCH v4 00/10] A couple of CI improvements","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-01-10T12:03:30Z","receivedAt":"2025-01-10T12:03:32Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 10, 2025 at 12:31:56PM +0100, Patrick Steinhardt wrote:\n\n> Changes in v4:\n> \n> - Improve the commit message of the SIGPIPE test commit to more\n> accurately describe the race.\n\nThank you for addressing my nits. :) The result looks good to me.\n\n-Peff\n"},{"id":"511150","messageId":"CAP8UFD1NX4C2jpbcb=CtX6w5qj3tZPchQ+bdHCX4x9fFqyBrBQ@mail.gmail.com","threadId":"62731","inReplyTo":"20250110-b4-pks-ci-fixes-v4-2-6e4613446080@pks.im","subject":"Re: [PATCH v4 02/10] t7422: fix flaky test caused by buffered stdout","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2025-01-24T09:16:19Z","receivedAt":"2025-01-24T09:16:33Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Fri, Jan 10, 2025 at 12:32 PM Patrick Steinhardt wrote:\n\n> Fix the issue by generating a couple thousand nested submodules and\n> matching on the first nested submodule. This ensures that the recursive\n> git-submodule(1) process completely fills its stdout buffer,\n\nThe patch looks great to me and I like the previous discussion with\nPeff about it. I just want to say that, after reading the discussion\nand then this paragraph, I wondered if it would have been possible to\ninstead have a `test-tool submodule` helper that would behave the same\nas `git submodule` except that it would call setvbuf() to reduce the\nsize of the stdout buffer. This might have allowed a test that didn't\nneed 2000 nested submodules, and thus might have been faster. No need\nto change anything though.\n\n> which makes\n> subsequent writes block until the downstream consumer of the pipe either\n> reads more or closes it.\n"},{"id":"511151","messageId":"CAP8UFD3cdA9P6-bm6XNFCapsUqEpVQ3Nw-2-5quAQMkT_p0sfQ@mail.gmail.com","threadId":"62731","inReplyTo":"20250110-b4-pks-ci-fixes-v4-3-6e4613446080@pks.im","subject":"Re: [PATCH v4 03/10] github: adapt containerized jobs to be rootless","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2025-01-24T09:56:17Z","receivedAt":"2025-01-24T09:56:31Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Fri, Jan 10, 2025 at 12:34 PM Patrick Steinhardt wrote:\n>\n> The containerized jobs in GitHub Actions run as root, giving them\n> special permissions to for example delete files even when the user\n> shouldn't be able to due to file permissions. This limitation keeps us\n> from using containerized jobs for most of our Ubuntu-based jobs as it\n> causes a number of tests to fail.\n>\n> Adapt the jobs to create a separate user that executes the test suite.\n> This follows similar infrastructure that we already have in GitLab CI.\n\nNit (not worth a reroll): It might help a bit to say something like:\n\n \"This requires installing the 'sudo' and 'shadow-utils' (for\n`useradd`) packages.\"\n"},{"id":"511152","messageId":"CAP8UFD0oYM6Cp=NQfN4p+FS3Mfdng1kXQxObtoOG2QuhPN-Aeg@mail.gmail.com","threadId":"62731","inReplyTo":"20250110-b4-pks-ci-fixes-v4-0-6e4613446080@pks.im","subject":"Re: [PATCH v4 00/10] A couple of CI improvements","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2025-01-24T09:59:04Z","receivedAt":"2025-01-24T09:59:18Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Fri, Jan 10, 2025 at 12:34 PM Patrick Steinhardt wrote:\n\n> this patch series addresses a couple of issues I've found while\n> investigating flaky CI jobs. Besides two more fixes for flaky jobs it\n> also removes some stale code and simplifies the setup on GitHub Actions\n> to always use containerized jobs on Linux.\n\nI left a few comments but I don't think they require a reroll. This\nseries looks good to me too.\n"},{"id":"511221","messageId":"Z5cvE8DkgTANo_0U@pks.im","threadId":"62731","inReplyTo":"CAP8UFD0oYM6Cp=NQfN4p+FS3Mfdng1kXQxObtoOG2QuhPN-Aeg@mail.gmail.com","subject":"Re: [PATCH v4 00/10] A couple of CI improvements","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-27T07:00:35Z","receivedAt":"2025-01-27T07:00:46Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Fri, Jan 24, 2025 at 10:59:04AM +0100, Christian Couder wrote:\n> On Fri, Jan 10, 2025 at 12:34 PM Patrick Steinhardt wrote:\n> \n> > this patch series addresses a couple of issues I've found while\n> > investigating flaky CI jobs. Besides two more fixes for flaky jobs it\n> > also removes some stale code and simplifies the setup on GitHub Actions\n> > to always use containerized jobs on Linux.\n> \n> I left a few comments but I don't think they require a reroll. This\n> series looks good to me too.\n\nThanks for your review!\n\nPatrick\n"},{"id":"525096","messageId":"e45b9487-b3ae-ed85-fd07-c92cfbf47cbb@gmx.de","threadId":"62731","inReplyTo":"20250110-b4-pks-ci-fixes-v4-3-6e4613446080@pks.im","subject":"Re: [PATCH v4 03/10] github: adapt containerized jobs to be rootless","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2025-08-28T09:58:38Z","receivedAt":"2025-08-28T09:58:46Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Patrick,\n\nOn Fri, 10 Jan 2025, Patrick Steinhardt wrote:\n\n> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\n> index 900be9957a23fcaa64e1aefd0c8638c5f84b7997..b02f5873a540b458d38e7951b4ee3d5ca598ae23 100644\n> --- a/.github/workflows/main.yml\n> +++ b/.github/workflows/main.yml\n> @@ -371,10 +371,12 @@ jobs:\n> run: apt -q update && apt -q -y install libc6-amd64 lib64stdc++6\n> - uses: actions/checkout@v4\n> - run: ci/install-dependencies.sh\n> - - run: ci/run-build-and-tests.sh\n> + - run: useradd builder --create-home\n> + - run: chown -R builder .\n> + - run: sudo --preserve-env --set-home --user=builder ci/run-build-and-tests.sh\n\nI am afraid that this is not enough. Sure, it works as long as the tests\nare passing, but the entire point of running the tests is to catch _and\ndebug_ when they are failing. Otherwise a lot of money and effort could be\nsaved simply by deleting those tests.\n\nWhen the tests are failing, the detailed test logs are supposed to be\nshown, but as I noticed most recently in\nhttps://github.com/microsoft/git/actions/runs/17278881863/job/49042596457?pr=787#step:9:1933\nthere is a fatal error that prevents them from being shown let alone\nuploaded:\n\n [...]\n Test Summary Report\n -------------------\n t5799-gvfs-helper.sh (Wstat: 256 Tests: 36 Failed: 1)\n Failed test: 25\n Non-zero exit status: 1\n Files=1040, Tests=31137, 543 wallclock secs ( 8.01 usr 2.16 sys + 611.98 cusr 1100.12 csys = 1722.27 CPU)\n Result: FAIL\n make[1]: *** [Makefile:78: prove] Error 1\n ++ cat exit.status\n make[1]: Leaving directory '/__w/git/git/t'\n make: *** [Makefile:3362: test] Error 2\n + res=2\n + rm exit.status\n + end_group 'Run tests'\n + test -n t\n + set +x\n ci/lib.sh: line 221: /__w/_temp/_runner_file_commands/set_env_cca39642-cc57-484c-b7d4-27bbd4dc8260: Permission denied\n Error: Process completed with exit code 1.\n\nThis error causes the next two steps to be skipped, the one that is\nsupposed to show the detailed test logs, and the one to upload the failed\ntests' directories, precluding any further attempt at debugging the test\nfailures. Even the part of that step that is supposed to show the failed\n_test case's_ logs, as a last resort, fails to show anything because it is\nskipped because of that error, too.\n\nDue to various reasons, I cannot investigate this any further. At the same\ntime, I suspect that you need some hack like adding the `builder` user to\nsome group that has write access to `/__w/_temp/` (which is most likely a\nDocker volume that maps to the host's `$RUNNER_TEMP` or some such, and\ntherefore a `chmod` is unlikely to work, or it might lead to unintended\nconsequences in later steps of thw workflow) to allow the logic to perform\nas desired.\n\nCiao,\nJohannes\n\n> - name: print test failures\n> if: failure() && env.FAILED_TEST_ARTIFACTS != ''\n> - run: ci/print-test-failures.sh\n> + run: sudo --preserve-env --set-home --user=builder ci/print-test-failures.sh\n> - name: Upload failed tests' directories\n> if: failure() && env.FAILED_TEST_ARTIFACTS != ''\n> uses: actions/upload-artifact@v4\n> diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh\n> index d1cb9fa8785388b3674fcea4dd682abc0725c968..ecb5b9d36c20d3e7e96148ac628a96c62642c308 100755\n> --- a/ci/install-dependencies.sh\n> +++ b/ci/install-dependencies.sh\n> @@ -31,7 +31,7 @@ alpine-*)\n> \t;;\n> fedora-*|almalinux-*)\n> \tdnf -yq update >/dev/null &&\n> -\tdnf -yq install make gcc findutils diffutils perl python3 gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null\n> +\tdnf -yq install shadow-utils sudo make gcc findutils diffutils perl python3 gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null\n> \t;;\n> ubuntu-*|ubuntu32-*|debian-*)\n> \t# Required so that apt doesn't wait for user input on certain packages.\n> \n> -- \n> 2.48.0.rc2.279.g1de40edade.dirty\n> \n> \n> \n"},{"id":"530826","messageId":"dda1d862-b5e2-9928-111c-fff519f6e00b@gmx.de","threadId":"62731","inReplyTo":"e45b9487-b3ae-ed85-fd07-c92cfbf47cbb@gmx.de","subject":"Re: [PATCH v4 03/10] github: adapt containerized jobs to be rootless","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2025-11-17T17:30:33Z","receivedAt":"2025-11-17T17:30:47Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Patrick, me again,\n\nOn Thu, 28 Aug 2025, Johannes Schindelin wrote:\n\n> On Fri, 10 Jan 2025, Patrick Steinhardt wrote:\n> \n> > diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\n> > index 900be9957a23fcaa64e1aefd0c8638c5f84b7997..b02f5873a540b458d38e7951b4ee3d5ca598ae23 100644\n> > --- a/.github/workflows/main.yml\n> > +++ b/.github/workflows/main.yml\n> > @@ -371,10 +371,12 @@ jobs:\n> > run: apt -q update && apt -q -y install libc6-amd64 lib64stdc++6\n> > - uses: actions/checkout@v4\n> > - run: ci/install-dependencies.sh\n> > - - run: ci/run-build-and-tests.sh\n> > + - run: useradd builder --create-home\n> > + - run: chown -R builder .\n> > + - run: sudo --preserve-env --set-home --user=builder ci/run-build-and-tests.sh\n> \n> I am afraid that this is not enough. Sure, it works as long as the tests\n> are passing, but the entire point of running the tests is to catch _and\n> debug_ when they are failing. Otherwise a lot of money and effort could be\n> saved simply by deleting those tests.\n> \n> When the tests are failing, the detailed test logs are supposed to be\n> shown, but as I noticed most recently in\n> https://github.com/microsoft/git/actions/runs/17278881863/job/49042596457?pr=787#step:9:1933\n> there is a fatal error that prevents them from being shown let alone\n> uploaded:\n> \n> [...]\n> Test Summary Report\n> -------------------\n> t5799-gvfs-helper.sh (Wstat: 256 Tests: 36 Failed: 1)\n> Failed test: 25\n> Non-zero exit status: 1\n> Files=1040, Tests=31137, 543 wallclock secs ( 8.01 usr 2.16 sys + 611.98 cusr 1100.12 csys = 1722.27 CPU)\n> Result: FAIL\n> make[1]: *** [Makefile:78: prove] Error 1\n> ++ cat exit.status\n> make[1]: Leaving directory '/__w/git/git/t'\n> make: *** [Makefile:3362: test] Error 2\n> + res=2\n> + rm exit.status\n> + end_group 'Run tests'\n> + test -n t\n> + set +x\n> ci/lib.sh: line 221: /__w/_temp/_runner_file_commands/set_env_cca39642-cc57-484c-b7d4-27bbd4dc8260: Permission denied\n> Error: Process completed with exit code 1.\n> \n> This error causes the next two steps to be skipped, the one that is\n> supposed to show the detailed test logs, and the one to upload the failed\n> tests' directories, precluding any further attempt at debugging the test\n> failures. Even the part of that step that is supposed to show the failed\n> _test case's_ logs, as a last resort, fails to show anything because it is\n> skipped because of that error, too.\n> \n> Due to various reasons, I cannot investigate this any further. At the same\n> time, I suspect that you need some hack like adding the `builder` user to\n> some group that has write access to `/__w/_temp/` (which is most likely a\n> Docker volume that maps to the host's `$RUNNER_TEMP` or some such, and\n> therefore a `chmod` is unlikely to work, or it might lead to unintended\n> consequences in later steps of thw workflow) to allow the logic to perform\n> as desired.\n\nI have contributed a patch for that via\nhttps://lore.kernel.org/git/pull.2003.git.1763399064983.gitgitgadget@gmail.com/.\nUnfortunately, I forgot to Cc: you, please accept my apologies for that\noversight.\n\nCiao,\nJohannes\n"}]}