From: Phillip Wood <phillip.wood123@gmail.com>
To: Harald Nordgren via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org
Cc: Ben Knoble <ben.knoble@gmail.com>,
Harald Nordgren <haraldnordgren@gmail.com>
Subject: Re: [PATCH v3 2/2] ci: point test failures and fixed known breakages at their file and line
Date: Wed, 30 Sep 2026 15:56:39 +0100 [thread overview]
Message-ID: <5529bccf-eeb1-40f9-ae03-8fa19dc26f5a@gmail.com> (raw)
In-Reply-To: <750c3605128c268f331b1b9477ca0489ced75543.1790748583.git.gitgitgadget@gmail.com>
Hi Harald
On 30/09/2026 07:09, 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 carries no file or line, so there is nothing to click
> through to from the GitHub UI.
Have you got an example of this? As I said in my last mail, I can't see
any links in the output from the linux-leaks job.
> Find the line a test is defined on by searching the script for its
> description as a fixed string, using the first match. A description
> can contain characters like `[` or `*` that a regex search would
> misread, so match it literally.
This second sentence doesn't really add anything - you've already said
we're searching for a fixed string.
> 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.
Ironically, it is the dynamically generated tests where a line number
would be most useful, but there is no easy way to determine what line we
should be using.
> A GitHub annotation is a single line, and a test description is always
> one line too, so only a `%` or a stray carriage return in it needs
> percent-encoding to keep the annotation intact. Escape `%` first, or a
> carriage return's own encoding would be mangled by a `%` substitution
> that ran after it.
Why do we need to escape the test descriptions when we haven't been
doing so up to now? Also if the test description is a single line why
are we worring about '\r'? If it is so important to escape the output
why does this patch not convert the existing annotations like the
"group::" on in the trailing context lines?
Thanks
Phillip
> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
> ---
> t/test-lib-github-workflow-markup.sh | 38 +++++++++++++++++++++++-----
> 1 file changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/t/test-lib-github-workflow-markup.sh b/t/test-lib-github-workflow-markup.sh
> index 0d54496358..66d2ccca18 100644
> --- a/t/test-lib-github-workflow-markup.sh
> +++ b/t/test-lib-github-workflow-markup.sh
> @@ -31,6 +31,22 @@ start_test_output () {
> github_markup_script_name=${0##*/}
> }
>
> +github_escape_message_ () {
> + # A test description is always one line, so only % and CR need
> + # escaping here. Escape % first, or CR's own %-encoding gets mangled.
> + # \r is not a portable sed escape, so splice in the actual byte.
> + sed -e 's/%/%25/g' -e "s/$(printf '\r')/%0D/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
> + # hit; -- keeps a description starting with "-" from being read as
> + # an option.
> + grep -n -F -- "$1" "$TEST_DIRECTORY/$github_markup_script_name" |
> + head -n 1 | cut -d: -f1
> +}
> +
> github_annotation_ () {
> echo >>$github_markup_output "::$1 file=$2,line=$3::$4"
> }
> @@ -40,18 +56,28 @@ github_annotation_ () {
> finalize_test_case_output () {
> test_case_result=$1
> shift
> +
> + case "$test_case_result" in
> + ok|broken)
> + # Exit without printing the "ok" or "broken" tests
> + return
> + ;;
> + 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"
> ;;
> fixed)
> - echo >>$github_markup_output "::notice::fixed: $this_test.$test_count $1"
> - ;;
> - ok|broken)
> - # 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"
> ;;
> esac
> +
> echo >>$github_markup_output "::group::$test_case_result: $this_test.$test_count $*"
> test-tool >>$github_markup_output path-utils skip-n-bytes \
> "$GIT_TEST_TEE_OUTPUT_FILE" $GIT_TEST_TEE_OFFSET
next prev parent reply other threads:[~2026-09-30 14:56 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-25 18:54 [PATCH] ci: point leak-sanitizer failures at the actual test and error Harald Nordgren via GitGitGadget
2026-09-25 20:26 ` Ben Knoble
2026-09-25 21:43 ` Harald Nordgren
2026-09-27 15:19 ` Phillip Wood
2026-09-27 19:52 ` Harald Nordgren
2026-09-28 18:54 ` [PATCH v2 0/2] ci: link failure and leak annotations to the test script Harald Nordgren via GitGitGadget
2026-09-28 18:54 ` [PATCH v2 1/2] ci: annotate leaks and stop a leak-sanitizer script at its first failure Harald Nordgren via GitGitGadget
2026-09-28 20:46 ` Junio C Hamano
2026-09-29 7:47 ` Harald Nordgren
2026-09-28 18:54 ` [PATCH v2 2/2] ci: point test failures and fixed known breakages at their file and line Harald Nordgren via GitGitGadget
2026-09-28 20:53 ` Junio C Hamano
2026-09-30 6:09 ` [PATCH v3 0/2] ci: link failure and leak annotations to the test script Harald Nordgren via GitGitGadget
2026-09-30 6:09 ` [PATCH v3 1/2] ci: annotate leaks and stop a leak-sanitizer script at its first failure Harald Nordgren via GitGitGadget
2026-09-30 14:56 ` Phillip Wood
2026-09-30 6:09 ` [PATCH v3 2/2] ci: point test failures and fixed known breakages at their file and line Harald Nordgren via GitGitGadget
2026-09-30 14:56 ` Phillip Wood [this message]
2026-09-30 18:40 ` Harald Nordgren
2026-09-30 14:37 ` [PATCH v3 0/2] ci: link failure and leak annotations to the test script Junio C Hamano
2026-09-30 15:52 ` Phillip Wood
2026-09-30 18:46 ` Junio C Hamano
2026-10-01 18:44 ` [PATCH v4 " Harald Nordgren via GitGitGadget
2026-10-01 18:44 ` [PATCH v4 1/2] ci: annotate leaks and stop a leak-sanitizer script at its first failure Harald Nordgren via GitGitGadget
2026-10-01 18:44 ` [PATCH v4 2/2] ci: point test failures and fixed known breakages at their file and line Harald Nordgren via GitGitGadget
2026-10-01 19:49 ` Phillip Wood
2026-10-01 20:11 ` Junio C Hamano
2026-10-02 8:04 ` Harald Nordgren
2026-10-03 8:11 ` [PATCH v5 0/2] ci: link failure and leak annotations to the test script Harald Nordgren via GitGitGadget
2026-10-03 8:11 ` [PATCH v5 1/2] ci: annotate leaks and stop a leak-sanitizer script at its first failure Harald Nordgren via GitGitGadget
2026-10-03 8:11 ` [PATCH v5 2/2] ci: point test failures and fixed known breakages at their file and line Harald Nordgren via GitGitGadget
2026-10-03 13:03 ` [PATCH v5 0/2] ci: link failure and leak annotations to the test script Phillip Wood
2026-10-03 19:02 ` Phillip Wood
2026-10-04 11:51 ` Harald Nordgren
2026-10-05 13:23 ` Phillip Wood
2026-10-05 13:59 ` Harald Nordgren
2026-10-05 15:11 ` Phillip Wood
2026-10-04 12:03 ` Harald Nordgren
2026-10-06 6:56 ` [PATCH v6 " Harald Nordgren via GitGitGadget
2026-10-06 6:56 ` [PATCH v6 1/2] ci: annotate leaks and stop a leak-sanitizer script at its first failure Harald Nordgren via GitGitGadget
2026-10-06 6:56 ` [PATCH v6 2/2] ci: point test failures and fixed known breakages at their file and line Harald Nordgren via GitGitGadget
2026-10-06 9:52 ` [PATCH v6 0/2] ci: link failure and leak annotations to the test script Phillip Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5529bccf-eeb1-40f9-ae03-8fa19dc26f5a@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=ben.knoble@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=haraldnordgren@gmail.com \
--cc=phillip.wood@dunelm.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox