Re: [PATCH v4 2/2] ci: point test failures and fixed known breakages at their file and line
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 1, 2026, 20:11 UTC
- Message-ID
- <xmqqld8h41vm.fsf@gitster.g>
- In-Reply-To
- <0e0972b7-65a2-46ce-84a9-7e403620802a@gmail.com>
Phillip Wood <phillip.wood123@gmail.com> writes:
Show 17 quoted lines
> 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.
Show 12 quoted lines
>> 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.