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

[Junio C Hamano <gitster@pobox.com>]

Phillip Wood <phillip.wood123@gmail.com> writes:

> Hi Harald
>
> On 01/10/2026 19:44, Harald Nordgren via GitGitGadget wrote:
>> From: Harald Nordgren <haraldnordgren@gmail.com>
>> 
>> 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?
>
>> 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.

>> 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.