Re: [PATCH 0/4] meson: parse TAP output generated by our tests

[Patrick Steinhardt <ps@pks.im>]

On Tue, May 06, 2025 at 02:29:35PM +0200, Patrick Steinhardt wrote:
> On Tue, May 06, 2025 at 12:59:49PM +0200, Patrick Steinhardt wrote:
> > Hi,
> > 
> > this patch series starts to parse TAP output generated by our tests when
> > executing them via Meson. This has the benefit that Meson starts to
> > understand skipped tests and reports how many subtests have been
> > executed:
> > 
> >     ```
> >     $ meson test t002*
> >     ninja: Entering directory `/home/pks/Development/git/build'
> >      1/10 t0024-crlf-archive                  OK              0.17s   2 subtests passed
> >      2/10 t0022-crlf-rename                   OK              0.18s   2 subtests passed
> >      3/10 t0029-core-unsetenvvars             SKIP            0.15s
> >      4/10 t0023-crlf-am                       OK              0.18s   2 subtests passed
> >      5/10 t0025-crlf-renormalize              OK              0.21s   3 subtests passed
> >      6/10 t0026-eol-config                    OK              0.25s   5 subtests passed
> >      7/10 t0020-crlf                          OK              0.81s   36 subtests passed
> >      8/10 t0028-working-tree-encoding         OK              0.85s   22 subtests passed
> >      9/10 t0021-conversion                    OK              3.45s   38 subtests passed
> >     10/10 t0027-auto-crlf                     OK             26.35s   2600 subtests passed
> >     
> >     Ok:                9
> >     Fail:              0
> >     Skipped:           1
> >     ```
> > 
> > This new feature is only enabled with Meson 1.8 and newer, which
> > contains a bugfix that we have upstreamed [1] to make the TAP parser
> > work in `meson test --interactive` mode.
> > 
> > Despite the changes to Meson itself, this patch series also contains a
> > couple of fixes for our test suite that caused us to not generate proper
> > TAP output.
> 
> Please hold off with merging this to "seen" just yet. I have missed that
> this introduces issues with MinGW, which I want to have a look at first
> before resubmitting. I didn't see those issues in a previous iteration,
> so I'm not sure whether it was introduced by this series or not.

Hm, this seems to have just been a CI flake. No idea why all of these
MinGW jobs failed all at once, but a rerun of the pipeline fixed all of
them.

Patrick