From: Todd Zullinger <tmz@pobox•com>
To: Junio C Hamano <gitster@pobox•com>
Cc: git@vger•kernel.org, Andrew Kreimer <algonell@gmail•com>,
Taylor Blau <me@ttaylorr•com>
Subject: Re: [PATCH] t1016: make sure to use specified GPG
Date: Sun, 12 Oct 2025 14:31:21 -0400 [thread overview]
Message-ID: <aOvz-ac8JTCaRwIm@teonanacatl.net> (raw)
In-Reply-To: <xmqq1pn85f5i.fsf@gitster.g>
Junio C Hamano wrote:
> Todd Zullinger <tmz@pobox•com> writes:
>
>> Interesting. And well-spotted.
>>
>> This _does_ seem to resolve the failures in our CI and in
>> the Fedora build system. I was able to run a few test
>> builds. With this fix, the tests were successful where they
>> were not without it.
>>
>> I remember suspecting the gpg calls were not using the
>> wrapper command in gpg.program. I even tried forcing the
>> --faked-system-time for all the tests to check that theory,
>> unsuccessfully.
>>
>> Oddly, I ran into test failures after fixing the GPG2 prereq
>> long before c348192afe (t1016: clean up style, 2024-10-22)
>> was in place. Perhaps I was hitting a different issue
>> initially? Then, when I looked at it again I didn't think
>> about gpg.program again, since I'd already tried to force
>> the gpg wrapper which sets --faked-system-time.
>>
>> It's both annoying and embarrassing if it is that simple and
>> I missed it after looking a few times, to be sure. But I'll
>> be happy with the end result all the same. :)
>
> FWIW, GitHub CI jobs are failing t1016 at the tip of 'seen' (which
> has this change), but only some and not all the jobs, which may
> indicate there are timeing-dependent flakes involved. I didn't dig
> further, though.
Ahh. When I saw this patch and checked the actions, I
looked at this job:
https://github.com/git/git/actions/runs/18418984778
and the failures all seemed to be unrelated to the test.
Looking again, I see the ps/ci-avoid-broken-sudo-on-ubuntu
branch was merged to seen to fix that problem.
Between that initial "success other than unrelated failures"
and my multiple successful runs in the previously-failing
Fedora build system, I thought it might have been fixed. :/
When I poked at these failures in the Fedora builds many
months ago, I was able to get the full test-results output
via a bit of a gross hack to tar it up and print it to the
build log as base64 text (only when there are failures):
# tar up test-results & $testdir, then print base64 encoded output
#
# copy $testdir contents to test-results to avoid absolute paths with tar
cp -a $testdir/* t/test-results/
begin='-----BEGIN BASE64 MESSAGE-----'
end='-----END BASE64 MESSAGE-----'
printf '\n%s\n' 'test-results and trash directory output follows; decode via:'
printf '%s\n' "sed -n '/^${begin}$/,/^${end}$/{/^${begin}$/!{/^${end}$/!p}}' \
build.log | base64 -d >output.tar.zst"
printf '%s\n' "$begin"
tar --warning=no-file-ignored -C t -cf - test-results/ | zstdmt -17 | base64
printf '%s\n' "$end"
I don't know if we have or might want something like that
for the Github/Gitlab CI.
Even with the test-results directory contents, I didn't
manage to work out what the issue was. Maybe some
additional debug output from the code and tests to show the
environment that is being used when gpg gets called to
make/verify the signatures could help. I didn't try to
adjust the code. I did add some debugging to the gpg
wrapper and used that wrapper by default, without success.
But I imagine that's mostly an issue with my unfamiliarity
with the code being tested. (The hacker version of "it's not
you, it's me.")
--
Todd
next prev parent reply other threads:[~2025-10-12 18:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-10 21:14 [PATCH] t1016: make sure to use specified GPG Junio C Hamano
2025-10-12 14:23 ` Todd Zullinger
2025-10-12 15:11 ` Junio C Hamano
2025-10-12 18:31 ` Todd Zullinger [this message]
2025-10-23 20:52 ` Junio C Hamano
2025-10-24 1:52 ` Todd Zullinger
2025-10-12 20:40 ` Andrew Kreimer
2025-10-13 15:38 ` Junio C Hamano
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=aOvz-ac8JTCaRwIm@teonanacatl.net \
--to=tmz@pobox$(echo .)com \
--cc=algonell@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=me@ttaylorr$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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