Just like we mark up test failures, it makes sense to mark up compile
errors, too.

In a sense, it makes even more sense with compile errors than with test
failures because we can link directly to the corresponding source code in
the former case (if said code has been touched by the Pull Request, that
is). The only downside is that this link currently is kind of misleading if
the Pull Request did not even touch the offending source code (such as was
the case when a GCC upgrade in Git for Windows' SDK all of a sudden pointed
out problems in the source code that had existed for a long time already).
We will see how the GitHub Actions engineers will develop this feature
further.

This patch series is based on js/ci-github-workflow-markup. Which also
serves as an example how this looks like if the offending source code was
not touched by the Pull Request:
https://github.com/gitgitgadget/git/actions/runs/2461737185 because it still
triggers the above-referenced GCC build failure.

Johannes Schindelin (2):
  ci(github): use grouping also in the `win-build` job
  ci(github): also mark up compile errors

 ci/lib.sh                 | 10 ++++++++--
 ci/make-test-artifacts.sh |  2 +-
 2 files changed, 9 insertions(+), 3 deletions(-)

base-commit: 3069f2a6f4c38e7e599067d2e4a8e31b4f53e2d3

Submitted-As: https://lore.kernel.org/git/pull.1253.git.1654774347.gitgitgadget@gmail.com