ci/run-build-and-tests: take a more high-level view
commitb95181cf822bde2c807127abd502683822d86cf8
authorJohannes Schindelin <johannes.schindelin@gmx.de>
Sat, 21 May 2022 22:18:48 +0000 (21 22:18 +0000)
committerJunio C Hamano <gitster@pobox.com>
Sat, 21 May 2022 23:25:55 +0000 (21 16:25 -0700)
tree1204f1ef3a3321311a7a6d1b85eca83fec15ace6
parent270ccd2a677766b7a7e22fdc16d6bb310eeda65b
ci/run-build-and-tests: take a more high-level view

In the web UI of GitHub workflows, failed runs are presented with the
job step that failed auto-expanded. In the current setup, this is not
helpful at all because that shows only the output of `prove`, which says
which test failed, but not in what way.

What would help understand the reader what went wrong is the verbose
test output of the failed test.

The logs of the failed runs do contain that verbose test output, but it
is shown in the _next_ step (which is marked as succeeding, and is
therefore _not_ auto-expanded). Anyone not intimately familiar with this
would completely miss the verbose test output, being left mostly
puzzled with the test failures.

We are about to show the failed test cases' output in the _same_ step,
so that the user has a much easier time to figure out what was going
wrong.

But first, we must partially revert the change that tried to improve the
CI runs by combining the `Makefile` targets to build into a single
`make` invocation. That might have sounded like a good idea at the time,
but it does make it rather impossible for the CI script to determine
whether the _build_ failed, or the _tests_. If the tests were run at
all, that is.

So let's go back to calling `make` for the build, and call `make test`
separately so that we can easily detect that _that_ invocation failed,
and react appropriately.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ci/run-build-and-tests.sh