indicate which of the joined tests failed

[geekosaur]

So people don't have to open all of the collapsed test output to find any failures.

---

Template B: This PR does not modify behaviour or interface

E.g. the PR only touches documentation or tests, does refactorings, etc.

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions).

[ulysses4ever]

thanks, that's an improvement.

It's still miles behind the native GitHub UI for separate steps, where if one step fails, it always gets you right to the point of failure.

[geekosaur]

I think you were the one who argued they should all be done in a single group because there were too many jobs otherwise?

And GitHub doesn't always get you to the actual point of failure: I had a whitespace issue initially, where the error output was at the top but GitHub dumped me at the bottom. And the whitespace job outputs every file it processed, meaning a lot of stuff to scroll past to get back up to the actual error message.

[ulysses4ever]

I think you were the one who argued they should all be done in a single group because there were too many jobs otherwise?

Not at all. All steps were collapsed to answer @mpickering 's request to set it up in a way that all steps always run.

The number of jobs of a separate issue.

And GitHub doesn't always get you to the actual point of failure

I thought so too, but it wasn't my experience with the one giant step

[geekosaur]

That can be done just by having them not depend on each other, with only the final job depending on them (as it already does) and always running (as it also does). The CI rewrite does it this way, and also splits out the validate-old-ghcs and dogfooding jobs the same way so they all run simultaneously and none of them failing blocks or kills the others.

[geekosaur]

@mergify backport 3.16

[mergify]

backport 3.16

✅ Backports have been created

• #11244 Backport #11242: indicate which of the joined tests failed has been created for branch 3.16 but encountered conflicts

[ulysses4ever]

If they stay in one job, it's more or less impossible as we discussed in the past I think. If they are distributed between several jobs, then, first, yes, the number of jobs explodes, but it's not all, because, second, you'll have to figure out how to thread the build state through the jobs otherwise you get a slowdown I think. (Although, this has to be measured.) So it's not trivial... Instead of all this complexity, it may be clearer to rollback to the old approach with separate steps in one job. The main body of the tests is the Package Tests anyway. Also, very rarely have I seen several steps failing at once.