git/ci/lib.sh, branch v2.37.2

ci(github): also mark up compile errors

2022-06-13T16:58:42Z

When GCC produces those helpful errors, we will want to present them in the GitHub workflow runs in the most helpful manner. To that end, we want to use workflow commands to render errors and warnings: https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions In the previous commit, we ensured that grouping is used for the build in all jobs, and this allows us to piggy-back onto the `group` function to transmogrify the output. Note: If `set -o pipefail` was available, we could do this in a little more elegant way. But since some of the steps are run using `dash`, we have to do a little `{ ...; echo $? >exit.status; } | ...` dance. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ci(github): bring back the 'print test failures' step

2022-06-08T23:12:37Z

Git now shows better information in the GitHub workflow runs when a test case failed. However, when a test case was implemented incorrectly and therefore does not even run, nothing is shown. Let's bring back the step that prints the full logs of the failed tests, and to improve the user experience, print out an informational message for readers so that they do not have to know/remember where to see the full logs. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ci(github): mention where the full logs can be found

2022-05-21T23:25:56Z

The full logs are contained in the `failed-tests-*.zip` artifacts that are attached to the failed CI run. Since this is not immediately obvious to the well-disposed reader, let's mention it explicitly. Suggested-by: Victoria Dye Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ci: use `--github-workflow-markup` in the GitHub workflow

2022-05-21T23:25:56Z

This makes the output easier to digest. Note: since workflow output currently cannot contain any nested groups (see https://github.com/actions/runner/issues/802 for details), we need to remove the explicit grouping that would span the entirety of each failed test script. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ci/run-build-and-tests: add some structure to the GitHub workflow output

2022-05-21T23:25:56Z

The current output of Git's GitHub workflow can be quite confusing, especially for contributors new to the project. To make it more helpful, let's introduce some collapsible grouping. Initially, readers will see the high-level view of what actually happened (did the build fail, or the test suite?). To drill down, the respective group can be expanded. Note: sadly, workflow output currently cannot contain any nested groups (see https://github.com/actions/runner/issues/802 for details), therefore we take pains to ensure to end any previous group before starting a new one. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ci: make it easier to find failed tests' logs in the GitHub workflow

2022-05-21T23:25:56Z

When investigating a test failure, the time that matters most is the time it takes from getting aware of the failure to displaying the output of the failing test case. You currently have to know a lot of implementation details when investigating test failures in the CI runs. The first step is easy: the failed job is marked quite clearly, but when opening it, the failed step is expanded, which in our case is the one running `ci/run-build-and-tests.sh`. This step, most notably, only offers a high-level view of what went wrong: it prints the output of `prove` which merely tells the reader which test script failed. The actually interesting part is in the detailed log of said failed test script. But that log is shown in the CI run's step that runs `ci/print-test-failures.sh`. And that step is _not_ expanded in the web UI by default. It is even marked as "successful", which makes it very easy to miss that there is useful information hidden in there. Let's help the reader by showing the failed tests' detailed logs in the step that is expanded automatically, i.e. directly after the test suite failed. This also helps the situation where the _build_ failed and the `print-test-failures` step was executed under the assumption that the _test suite_ failed, and consequently failed to find any failed tests. An alternative way to implement this patch would be to source `ci/print-test-failures.sh` in the `handle_test_failures` function to show these logs. However, over the course of the next few commits, we want to introduce some grouping which would be harder to achieve that way (for example, we do want a leaner, and colored, preamble for each failed test script, and it would be trickier to accommodate the lack of nested groupings in GitHub workflows' output). Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ci: fix code style

2022-05-21T23:25:55Z

In b92cb86ea14 (travis-ci: check that all build artifacts are .gitignore-d, 2017-12-31), a function was introduced with a code style that is different from the surrounding code: it added the opening curly brace on its own line, when all the existing functions in the same file cuddle that brace on the same line as the function name. Let's make the code style consistent again. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

CI: select CC based on CC_PACKAGE (again)

2022-04-22T18:28:17Z

Fix a regression in 707d2f2fe86 (CI: use "$runs_on_pool", not "$jobname" to select packages & config, 2021-11-23). In that commit I changed CC=gcc from CC=gcc-9, but on OSX the "gcc" in $PATH points to clang, we need to use gcc-9 instead. Likewise for the linux-gcc job CC=gcc-8 was changed to the implicit CC=gcc, which would select GCC 9.4.0 instead of GCC 8.4.0. Furthermore in 25715419bf4 (CI: don't run "make test" twice in one job, 2021-11-23) when the "linux-TEST-vars" job was split off from "linux-gcc" the "cc_package: gcc-8" line was copied along with it, so its "cc_package" line wasn't working as intended either. As a table, this is what's changed by this commit, i.e. it only affects the linux-gcc, linux-TEST-vars and osx-gcc jobs: |-------------------+-----------+-------------------+-------+-------| | jobname | vector.cc | vector.cc_package | old | new | |-------------------+-----------+-------------------+-------+-------| | linux-clang | clang | - | clang | clang | | linux-sha256 | clang | - | clang | clang | | linux-gcc | gcc | gcc-8 | gcc | gcc-8 | | osx-clang | clang | - | clang | clang | | osx-gcc | gcc | gcc-9 | clang | gcc-9 | | linux-gcc-default | gcc | - | gcc | gcc | | linux-TEST-vars | gcc | gcc-8 | gcc | gcc-8 | |-------------------+-----------+-------------------+-------+-------| Reported-by: Carlo Arenas Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

compat: auto-detect if zlib has uncompress2()

2022-01-26T17:05:55Z

We have a copy of uncompress2() implementation in compat/ so that we can build with an older version of zlib that lack the function, and the build procedure selects if it is used via the NO_UNCOMPRESS2 $(MAKE) variable. This is yet another "annoying" knob the porters need to tweak on platforms that are not common enough to have the default set in the config.mak.uname file. Attempt to instead ask the system header to decide if we need the compatibility implementation. This is a deviation from the way we have been handling the "compatiblity" features so far, and if it can be done cleanly enough, it could work as a model for features that need compatibility definition we discover in the future. With that goal in mind, avoid expedient but ugly hacks, like shoving the code that is conditionally compiled into an unrelated .c file, which may not work in future cases---instead, take an approach that uses a file that is independently compiled and stands on its own. Compile and link compat/zlib-uncompress2.c file unconditionally, but conditionally hide the implementation behind #if/#endif when zlib version is 1.2.9 or newer, and unconditionally archive the resulting object file in the libgit.a to be picked up by the linker. There are a few things to note in the shape of the code base after this change: - We no longer use NO_UNCOMPRESS2 knob; if the system header claims a version that is more cent than the library actually is, this would break, but it is easy to add it back when we find such a system. - The object file compat/zlib-uncompress2.o is always compiled and archived in libgit.a, just like a few other compat/ object files already are. - The inclusion of is done in ; we used to do so from which includes as the first thing it does, so from the *.c codes, there is no practical change. - Until objects in libgit.a that is already used gains a reference to the function, the reftable code will be the only one that wants it, so libgit.a on the linker command line needs to appear once more at the end to satisify the mutual dependency. - Beat found a trick used by OpenSSL to avoid making the conditionally-compiled object truly empty (apparently because they had to deal with compilers that do not want to see an effectively empty input file). Our compat/zlib-uncompress2.c file borrows the same trick for portabilty. Signed-off-by: Ævar Arnfjörð Bjarmason Helped-by: Beat Bolli Signed-off-by: Junio C Hamano

Merge branch 'ab/ci-updates'

2021-12-15T17:39:49Z

Drop support for TravisCI and update test workflows at GitHub. * ab/ci-updates: CI: don't run "make test" twice in one job CI: use "$runs_on_pool", not "$jobname" to select packages & config CI: rename the "Linux32" job to lower-case "linux32" CI: use shorter names that fit in UX tooltips CI: remove Travis CI support