From: Todd Zullinger <tmz@pobox.com>
Date: Sun, 12 Oct 2025 18:31:21 GMT
Subject: Re: [PATCH] t1016: make sure to use specified GPG
Message-ID: <aOvz-ac8JTCaRwIm@teonanacatl.net>
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