git/ci, branch v2.45.1

fuzz: add fuzzer for config parsing

2024-03-15T17:47:05Z

Add a new fuzz target that exercises the parsing of git configs. The existing git_config_from_mem function is a perfect entry point for fuzzing as it exercises the same code paths as the rest of the config parsing functions and offers an easily fuzzable interface. Config parsing is a useful thing to fuzz because it operates on user controlled data and is a central component of many git operations. Signed-off-by: Brian C Tracy Signed-off-by: Junio C Hamano

ci: add jobs to test with the reftable backend

2024-02-07T16:28:37Z

Add CI jobs for both GitHub Workflows and GitLab CI to run Git with the new reftable backend. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'js/oss-fuzz-build-in-ci'

2024-01-30T00:03:00Z

oss-fuzz tests are built and run in CI. * js/oss-fuzz-build-in-ci: ci: build and run minimal fuzzers in GitHub CI fuzz: fix fuzz test build rules

ci: build and run minimal fuzzers in GitHub CI

2024-01-19T22:29:25Z

To prevent bitrot, we would like to regularly exercise the fuzz tests in order to make sure they still link & run properly. We already compile the fuzz test objects as part of the default `make` target, but we do not link the executables due to the fuzz tests needing specific compilers and compiler features. This has lead to frequent build breakages for the fuzz tests. To remedy this, we can add a CI step to actually link the fuzz executables, and run them (with finite input rather than the default infinite random input mode) to verify that they execute properly. Since the main use of the fuzz tests is via OSS-Fuzz [1], and OSS-Fuzz only runs tests on Linux [2], we only set up a CI test for the fuzzers on Linux. [1] https://github.com/google/oss-fuzz [2] https://google.github.io/oss-fuzz/further-reading/fuzzer-environment/ Signed-off-by: Josh Steadmon Signed-off-by: Junio C Hamano

ci: add macOS jobs to GitLab CI

2024-01-18T19:53:17Z

Add a job to GitLab CI which runs tests on macOS, which matches the equivalent "osx-clang" job that we have for GitHub Workflows. One significant difference though is that this new job runs on Apple M1 machines and thus uses the "arm64" architecture. As GCC does not yet support this comparatively new architecture we cannot easily include an equivalent for the "osx-gcc" job that exists in GitHub Workflows. Note that one test marked as `test_must_fail` is surprisingly passing: t7815-grep-binary.sh (Wstat: 0 Tests: 22 Failed: 0) TODO passed: 12 This seems to boil down to an unexpected difference in how regcomp(3P) works when matching NUL bytes. Cross-checking with the respective GitHub job shows that this is not an issue unique to the GitLab CI job as it passes in the same way there. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

ci: make p4 setup on macOS more robust

2024-01-18T19:53:17Z

When setting up Perforce on macOS we put both `p4` and `p4d` into "$HOME/bin". On GitHub CI this directory is indeed contained in the PATH environment variable and thus there is no need for additional setup than to put the binaries there. But GitLab CI does not do this, and thus our Perforce-based tests would be skipped there even though we download the binaries. Refactor the setup code to become more robust by downloading binaries into a separate directory which we then manually append to our PATH. This matches what we do on Linux-based jobs. Note that it may seem like we already did append "$HOME/bin" to PATH because we're actually removing the lines that adapt PATH. But we only ever adapted the PATH variable in "ci/install-dependencies.sh", and didn't adapt it when running "ci/run-build-and-test.sh". Consequently, the required binaries wouldn't be found during the test run unless the CI platform already had the "$HOME/bin" in PATH right from the start. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

ci: handle TEST_OUTPUT_DIRECTORY when printing test failures

2024-01-18T19:53:17Z

The TEST_OUTPUT_DIRECTORY environment variable can be used to instruct the test suite to write test data and test results into a different location than into "t/". The "ci/print-test-failures.sh" script does not know to handle this environment variable though, which means that it will search for test results in the wrong location if it was set. Update the script to handle TEST_OUTPUT_DIRECTORY so that we can start to set it in our CI. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

ci: add job performing static analysis on GitLab CI

2024-01-08T19:23:03Z

Our GitHub Workflows definitions have a static analysis job that runs the following tasks: - Coccinelle to check for suggested refactorings. - `make hdr-check` to check for missing includes or forward declarations in our header files. - `make check-pot` to check our translations for issues. - `./ci/check-directional-formatting.bash` to check whether our sources contain any Unicode directional formatting code points. Add an equivalent job to our GitLab CI definitions. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'js/ci-discard-prove-state'

2023-12-10T00:37:48Z

The way CI testing used "prove" could lead to running the test suite twice needlessly, which has been corrected. * js/ci-discard-prove-state: ci: avoid running the test suite _twice_

Merge branch 'ps/ci-gitlab'

2023-12-10T00:37:48Z

Add support for GitLab CI. * ps/ci-gitlab: ci: add support for GitLab CI ci: install test dependencies for linux-musl ci: squelch warnings when testing with unusable Git repo ci: unify setup of some environment variables ci: split out logic to set up failed test artifacts ci: group installation of Docker dependencies ci: make grouping setup more generic ci: reorder definitions for grouping functions