Thread (40 messages) 40 messages, 5 authors, 3d ago

Re: [PATCH v4 2/2] ci: point test failures and fixed known breakages at their file and line

flat view

From: Junio C Hamano <hidden>
Date: 2026-10-01 20:11:44

Phillip Wood [off-list ref] writes:
Hi Harald

On 01/10/2026 19:44, Harald Nordgren via GitGitGadget wrote:
quoted
From: Harald Nordgren <redacted>

A test failure or a fixed known breakage gets an annotation that names
the test but says nothing about where it's defined, so a reviewer has
to search the script by hand to find it.
I'm afraid I'm still not clear what this does in practical terms. What 
appears in the test output that the user sees that didn't before?
quoted
Find the line a test is defined on by searching the script for its
description as a fixed string, using the first match. Fall back to
line 1 when the description is not found verbatim, which happens when
a test builds its description at runtime instead of writing it out
literally.
I agree this is still hard to read.  My interpretation of the above
is

    We only say "the t1234 script failed" (in the first paragraph
    that makes an observation of the status quo), and we try to find
    the test_expect_success block and show it as the finer-grained
    clue (the second paragraph).

but that may be way off the mark.
quoted
A GitHub annotation is a single line, so a `%` in a test description
has to be percent-encoded as `%25`, or GitHub misreads it as its own
escape sequence. for-each-ref's format atoms use plenty of them, e.g.
`%(raw)`.
That's a useful example of why we want to escape the output which makes 
it all the more puzzling that we don't escape the existing annotations 
that I mentioned last time.

Thanks

Phillip
Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help