git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v5 0/2] ci: link failure and leak annotations to the test script

From
PWPhillip Wood <phillip.wood123@gmail.com>
Date
Oct 3, 2026, 13:03 UTC
Message-ID
<3587bf44-1b3b-422f-a926-f8481104dfd8@gmail.com>
In-Reply-To
<pull.2419.v5.git.git.1791015117.gitgitgadget@gmail.com>
Hi Harald
On 03/10/2026 09:11, Harald Nordgren via GitGitGadget wrote:
Show 5 quoted lines
> Link failure and leak annotations in CI to the test script, so both can be
> found from the job summary.
> 
> V5 CI Job where failures and leaks are reported:
> https://github.com/git/git/actions/runs/36979818141/job/110752027863?pr=2426

There does not appear to be any output relating to leaks in that job. The first patch hasn't changed so I'm not sure why that is.

Show 6 quoted lines
> Changes in v5:
> 
>   * Removed % escaping entirely, verified on CI that it isn't needed. Every
>     existing test description that uses % renders correctly unescaped.
>   * Rewrote the file/line commit message with a concrete example (failed:
>     t1060.17 partial clone of corrupted repository).
You have added
     When a test fails, GitHub shows an annotation naming it, for
     example:
         failed: t1060.17 partial clone of corrupted repository

which shows an example of the current output without the filename or line annotations. There is no example of what that output changes to, so there is no way for someone reading that message to see what has actually changed. After spending some time clicking around in Github I think what that patch changes is not the test output of individual jobs which you linked to above, but what is displayed on the summary page at

https://github.com/git/git/actions/runs/36979818141?pr=2426

That page shows a list of annotations with links to the changes in the failed test file. That is a useful improvement but how you expected someone reading the commit message to understand what had changed when you did not give an example of the new output, and the changes are on a different page to the one you linked to in the cover letter is beyond me. I'm pretty exasperated that I've had to spend time messing about on Github trying to see what has changed because you could not provide a link and write a couple of sentences explaining it. After asking what this change did in v3 you replied that the commit message wasn't clear without explaining what the change actually did. When I asked what the change did in practical terms in response to v4 I got no reply. As you already know reviewer time is short on this list, so please, when someone asks a question answer it rather than replying with an obtuse comment or simply ignoring it and sending another patch.

Both these patches are useful improvements, but trying to get an explanation of what they did has been like trying getting blood out of a stone.

Thanks
Phillip
Show 117 quoted lines
> Changes in v4:
> 
>   * Clarify commit messages and simplify escaping logic.
> 
> Changes in v3:
> 
>   * Fixed bug in the --immediate exit ordering: the --immediate &&
>     --invert-exit-code path called exit 0 before the test's annotation was
>     written, now a single unconditional call covers both exit paths.
>   * github_escape_message_ no longer relies on \r being a portable sed escape
>     sequence (not POSIX-guaranteed and BSD sed implementations can differ),
>     it splices in the literal carriage-return byte via printf instead.
>   * Reverted unrelated test-tool line back to its original form.
> 
> Changes in v2:
> 
>   * Split into two commits, each explaining its own reasoning.
>   * Leak output is no longer capped or embedded in the message, it's now an
>     uncapped fold, so multiple leaks in the same test both show in full. A
>     second leak in a different test still won't show in the same run,
>     --immediate stops the script at the first failure, but it no longer gets
>     buried under every later test falsely reporting "not ok" either.
>   * Drops the giant unfolded message that annotations used to carry, which is
>     what probably caused the scrolling behavior.
> 
> Harald Nordgren (2):
>    ci: annotate leaks and stop a leak-sanitizer script at its first
>      failure
>    ci: point test failures and fixed known breakages at their file and
>      line
> 
>   ci/lib.sh                            |  1 +
>   t/test-lib-github-workflow-markup.sh | 46 ++++++++++++++++++++++++----
>   t/test-lib.sh                        |  6 +++-
>   3 files changed, 46 insertions(+), 7 deletions(-)
> 
> 
> base-commit: c46c1e37724f0478939de636ab8ea5a89086d532
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2419%2FHaraldNordgren%2Fci-annotation-file-line-v5
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2419/HaraldNordgren/ci-annotation-file-line-v5
> Pull-Request: https://github.com/git/git/pull/2419
> 
> Range-diff vs v4:
> 
>   1:  138394b48b = 1:  851efeec8b ci: annotate leaks and stop a leak-sanitizer script at its first failure
>   2:  8ec2b53d82 ! 2:  46f93a9e16 ci: point test failures and fixed known breakages at their file and line
>       @@ Metadata
>         ## Commit message ##
>            ci: point test failures and fixed known breakages at their file and line
>        
>       -    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.
>       +    When a test fails, GitHub shows an annotation naming it, for example:
>        
>       -    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
>       +        failed: t1060.17 partial clone of corrupted repository
>       +
>       +    but the location GitHub attaches to that annotation is the CI
>       +    workflow file itself, not the test script, so there is nothing
>       +    pointing at where the test actually lives.
>       +
>       +    Find the line a test is defined on by searching its script for the
>       +    test's own description as a fixed string, using the first match, and
>       +    attach that file and line to the annotation instead. 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.
>        
>       -    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)`.
>       -
>            Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
>        
>         ## t/test-lib-github-workflow-markup.sh ##
>       @@ t/test-lib-github-workflow-markup.sh: start_test_output () {
>         	github_markup_script_name=${0##*/}
>         }
>         
>       -+github_escape_message_ () {
>       -+	# % has to be escaped or GitHub misreads it as the start of its own
>       -+	# percent-encoding (e.g. a literal %(raw) in a for-each-ref test
>       -+	# description).
>       -+	sed -e 's/%/%25/g'
>       -+}
>       -+
>        +find_test_case_line_ () {
>        +	# A description can contain characters like [ or * that would
>        +	# corrupt a regex search, so match it literally and take the first
>       @@ t/test-lib-github-workflow-markup.sh: github_annotation_ () {
>        +	esac
>        +
>        +	test_case_line=$(find_test_case_line_ "$1")
>       -+	test_case_description=$(printf '%s' "$1" | github_escape_message_)
>        +
>         	case "$test_case_result" in
>         	failure)
>        -		echo >>$github_markup_output "::error::failed: $this_test.$test_count $1"
>        +		github_annotation_ error "t/$github_markup_script_name" "${test_case_line:-1}" \
>       -+			"failed: $this_test.$test_count $test_case_description"
>       ++			"failed: $this_test.$test_count $1"
>         		;;
>         	fixed)
>        -		echo >>$github_markup_output "::notice::fixed: $this_test.$test_count $1"
>       @@ t/test-lib-github-workflow-markup.sh: github_annotation_ () {
>        -		# Exit without printing the "ok" or ""broken" tests
>        -		return
>        +		github_annotation_ notice "t/$github_markup_script_name" "${test_case_line:-1}" \
>       -+			"fixed: $this_test.$test_count $test_case_description"
>       ++			"fixed: $this_test.$test_count $1"
>         		;;
>         	esac
>        +
> 
Previous: Harald Nordgren via GitGitGadgetNext: Phillip Wood
Message 30 of 40 in “ci: point leak-sanitizer failures at the actual test and error”
  1. ci: point leak-sanitizer failures at the actual test and errorHarald Nordgren via GitGitGadget, Sep 25, 2026
  2. Ben KnobleSep 25, 2026
  3. Harald NordgrenSep 25, 2026
  4. Phillip WoodSep 27, 2026
  5. Harald NordgrenSep 27, 2026
  6. 0/2 ci: link failure and leak annotations to the test scriptHarald Nordgren via GitGitGadget, Sep 28, 2026
  7. 2/2 ci: point test failures and fixed known breakages at their file and lineHarald Nordgren via GitGitGadget, Sep 28, 2026
  8. Junio C HamanoSep 28, 2026
  9. 1/2 ci: annotate leaks and stop a leak-sanitizer script at its first failureHarald Nordgren via GitGitGadget, Sep 28, 2026
  10. Junio C HamanoSep 28, 2026
  11. Harald NordgrenSep 29, 2026
  12. 0/2 ci: link failure and leak annotations to the test scriptHarald Nordgren via GitGitGadget, Sep 30, 2026
  13. 1/2 ci: annotate leaks and stop a leak-sanitizer script at its first failureHarald Nordgren via GitGitGadget, Sep 30, 2026
  14. Phillip WoodSep 30, 2026
  15. 2/2 ci: point test failures and fixed known breakages at their file and lineHarald Nordgren via GitGitGadget, Sep 30, 2026
  16. Phillip WoodSep 30, 2026
  17. Harald NordgrenSep 30, 2026
  18. Junio C HamanoSep 30, 2026
  19. Phillip WoodSep 30, 2026
  20. Junio C HamanoSep 30, 2026
  21. 0/2 ci: link failure and leak annotations to the test scriptHarald Nordgren via GitGitGadget, Oct 1, 2026
  22. 1/2 ci: annotate leaks and stop a leak-sanitizer script at its first failureHarald Nordgren via GitGitGadget, Oct 1, 2026
  23. 2/2 ci: point test failures and fixed known breakages at their file and lineHarald Nordgren via GitGitGadget, Oct 1, 2026
  24. Phillip WoodOct 1, 2026
  25. Junio C HamanoOct 1, 2026
  26. Harald NordgrenOct 2, 2026
  27. 0/2 ci: link failure and leak annotations to the test scriptHarald Nordgren via GitGitGadget, Oct 3, 2026
  28. 1/2 ci: annotate leaks and stop a leak-sanitizer script at its first failureHarald Nordgren via GitGitGadget, Oct 3, 2026
  29. 2/2 ci: point test failures and fixed known breakages at their file and lineHarald Nordgren via GitGitGadget, Oct 3, 2026
  30. Phillip WoodOct 3, 2026
  31. Phillip WoodOct 3, 2026
  32. Harald NordgrenOct 4, 2026
  33. Phillip WoodOct 5, 2026
  34. Harald NordgrenOct 5, 2026
  35. Phillip WoodOct 5, 2026
  36. Harald NordgrenOct 4, 2026
  37. 0/2 ci: link failure and leak annotations to the test scriptHarald Nordgren via GitGitGadget, Oct 6, 2026
  38. 1/2 ci: annotate leaks and stop a leak-sanitizer script at its first failureHarald Nordgren via GitGitGadget, Oct 6, 2026
  39. 2/2 ci: point test failures and fixed known breakages at their file and lineHarald Nordgren via GitGitGadget, Oct 6, 2026
  40. Phillip WoodOct 6, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.