git/ci, branch v2.44.0

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

Merge branch 'js/doc-unit-tests'

2023-12-10T00:37:47Z

Process to add some form of low-level unit tests has started. * js/doc-unit-tests: ci: run unit tests in CI unit tests: add TAP unit test framework unit tests: add a project plan document

ci: avoid running the test suite _twice_

2023-11-14T00:24:23Z

This is a late amendment of 4a6e4b960263 (CI: remove Travis CI support, 2021-11-23), whereby the `.prove` file (being written by the `prove` command that is used to run the test suite) is no longer retained between CI builds: This feature was only ever used in the Travis CI builds, we tried for a while to do the same in Azure Pipelines CI runs (but I gave up on it after a while), and we never used that feature in GitHub Actions (nor does the new GitLab CI code use it). Retaining the Prove cache has been fragile from the start, even though the idea seemed good at the time, the idea being that the `.prove` file caches information about previous `prove` runs (`save`) and uses them (`slow`) to run the tests in the order from longer-running to shorter ones, making optimal use of the parallelism implied by `--jobs=`. However, using a Prove cache can cause some surprising behavior: When the `prove` caches information about a test script it has run, subsequent `prove` runs (with `--state=slow`) will run the same test script again even if said script is not specified on the `prove` command-line! So far, this bug did not matter. Right until d8f416bbb87c (ci: run unit tests in CI, 2023-11-09) did it not matter. But starting with that commit, we invoke `prove` _twice_ in CI, once to run the regular test suite of regression test scripts, and once to run the unit tests. Due to the bug, the second invocation re-runs all of the tests that were already run as part of the first invocation. This not only wastes build minutes, it also frequently causes the `osx-*` jobs to fail because they already take a long time and now are likely to run into a timeout. The worst part about it is that there is actually no benefit to keep running with `--state=slow,save`, ever since we decided no longer to try to reuse the Prove cache between CI runs. So let's just drop that Prove option and live happily ever after. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano