Re: [PATCH] t1016: make sure to use specified GPG

From: Todd Zullinger <tmz@pobox.com>
Date: Oct 12, 2025, 18:31 UTC
Message-ID: <aOvz-ac8JTCaRwIm@teonanacatl.net>
In-Reply-To: <xmqq1pn85f5i.fsf@gitster.g>

Junio C Hamano wrote:

Show 29 quoted lines

> 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