git/.github/workflows, branch v2.37.2

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: 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

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

Merge branch 'hk/ci-checkwhitespace-commentfix'

2021-12-10T22:35:12Z

Comment fix. * hk/ci-checkwhitespace-commentfix: ci(check-whitespace): update stale file top comments

Merge branch 'js/ci-no-directional-formatting'

2021-12-10T22:35:06Z

CI has been taught to catch some Unicode directional formatting sequence that can be used in certain mischief. * js/ci-no-directional-formatting: ci: disallow directional formatting

CI: don't run "make test" twice in one job

2021-11-24T00:51:54Z

The "linux-clang" and "linux-gcc" jobs both run "make test" twice, but with different environment variables. Running these in sequence seems to have been done to work around some constraint on Travis, see ae59a4e44f3 (travis: run tests with GIT_TEST_SPLIT_INDEX, 2018-01-07). By having these run in parallel we'll get jobs that finish much sooner than they otherwise would have. We can also simplify the control flow in "ci/run-build-and-tests.sh" as a result, since we won't run "make test" twice we don't need to run "make" twice at all, let's default to "make all test" after setting the variables, and then override it to just "all" for the compile-only tests. Add a comment to clarify that new "test" targets should adjust $MAKE_TARGETS rather than being added after the "case/esac". This should avoid future confusion where e.g. the compilation-only "pedantic" target will unexpectedly start running tests. See [1] and [2]. 1. https://lore.kernel.org/git/211122.86ee78yxts.gmgdl@evledraar.gmail.com/ 2. https://lore.kernel.org/git/211123.86ilwjujmd.gmgdl@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

CI: use "$runs_on_pool", not "$jobname" to select packages & config

2021-11-24T00:51:53Z

Change the setup hooks for the CI to use "$runs_on_pool" for the "$regular" job. Now we won't need as much boilerplate when adding new jobs to the "regular" matrix, see 956d2e4639b (tests: add a test mode for SANITIZE=leak, run it in CI, 2021-09-23) for the last such commit. I.e. now instead of needing to enumerate each jobname when we select packages we can install things depending on the pool we're running in. That we didn't do this dates back to the now gone dependency on Travis CI, but even if we add a new CI target in the future this'll be easier to port over, since we can probably treat "ubuntu-latest" as a stand-in for some recent Linux that can run "apt" commands. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

CI: rename the "Linux32" job to lower-case "linux32"

2021-11-24T00:51:53Z

As a follow-up to the preceding commit's shortening of CI job names, rename the only job that starts with an upper-case letter to be consistent with the rest. It was added in 88dedd5e72c (Travis: also test on 32-bit Linux, 2017-03-05). Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

CI: use shorter names that fit in UX tooltips

2021-11-24T00:51:53Z

Change the names used for the GitHub CI workflows to be short enough to (mostly) fit in the pop-up tool-tips that GitHub shows in the commit view. I.e. when mouse-clicking on the passing or failing check-mark next to the commit subject. These names are seemingly truncated to 17-20 characters followed by three dots ("..."). Since a "CI/PR / " prefix is added to them the job names looked like this before (windows-test and vs-test jobs omitted): CI/PR / ci-config (p... CI/PR / windows-buil... CI/PR / vs-build (pu... CI/PR / regular (lin... CI/PR / regular (lin... CI/PR / regular (os... CI/PR / regular (os... CI/PR / regular (lin... CI/PR / regular (lin... CI/PR / dockerized (... CI/PR / dockerized (... CI/PR / dockerized (... CI/PR / static-anal... CI/PR / sparse (pu... CI/PR / documenta... By omitting the "/PR" from the top-level name, and pushing the $jobname to the front we'll now instead get: CI / config (push) CI / win build (push... CI / win+VS build (... CI / linux-clang (ub... CI / linux-gcc (ubun... CI / osx-clang (osx)... CI / osx-gcc (osx) (... CI / linux-gcc-defau... CI / linux-leaks (ub... CI / linux-musl (alp... CI / Linux32 (daald/... CI / pedantic (fedor... CI / static-analysis... CI / sparse (push)... CI / documentation We then have no truncation in the expanded view. See [1] for how it looked before, [2] for a currently visible CI run using this commit, and [3] for the GitHub workflow syntax involved being changed here. Let's also use the existing "pool" field as before. It's occasionally useful to know we're running on say ubuntu v.s. fedora. The "-latest" suffix is useful to some[4], and since it's now at the end it doesn't hurt readability in the short view compared to saying "ubuntu" or "macos". 1. https://github.com/git/git/tree/master/ 2. https://github.com/avar/git/tree/avar/ci-rm-travis-cleanup-ci-names-3 3. https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions 3. https://lore.kernel.org/git/d9b07ca5-b58d-a535-d25b-85d7f12e6295@github.com/ Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

ci(check-whitespace): update stale file top comments

2021-11-19T22:45:33Z

Earlier a066a90d (ci(check-whitespace): restrict to the intended commits, 2021-07-14) changed the check-whitespace task to stop using a shallow clone, and cc003621 (ci(check-whitespace): stop requiring a read/write token, 2021-07-14) changed the way how the errors the task discovered is signaled back to the user. They however forgot to update the comment that outlines what is done in the task. Correct them. Signed-off-by: Hans Krentel (hakre) Signed-off-by: Junio C Hamano