Re: [PATCH 0/2] t/lib-gpg: ensure GNUPGHOME is created as needed
Junio C Hamano <gitster@pobox.com> writes:
Show 38 quoted lines
> Todd Zullinger <tmz@pobox.com> writes:
>
>> I've intended to dig into it further over the past few
>> months but have not managed to spend enough time to work out
>> the root of the problem.
>>
>> I hope that someone more familiar with these tests (or
>> perhaps someone with fresh eyes) will spot the problem.
>>>
>>> A number of these fail, e.g.:
>>>
>>> https://github.com/tmzullinger/git/actions/runs/9780387020/job/27001952643#step:4:1871
>>>
>>> Error: failed: t1016.173 Verify commit signedcommit4's sha1 oid
>>> failure: t1016.173 Verify commit signedcommit4's sha1 oid
>>> git --git-dir=repo-sha256/.git rev-parse --output-object-format=sha1 ${sha256_oid} > ${name}_sha1 &&
>>> test_cmp ${name}_sha1 ${name}_sha1_expected
>>>
>>> + git --git-dir=repo-sha256/.git rev-parse --output-object-format=sha1 5d70155cc40e4c16515c89ad0b11d8c691436fc4a4d3ca246669a4c21f07e454
>>> + test_cmp signedcommit4_sha1 signedcommit4_sha1_expected
>>> + test 2 -ne 2
>>> + eval diff -u "$@"
>>> + diff -u signedcommit4_sha1 signedcommit4_sha1_expected
>>> --- signedcommit4_sha1 2024-07-03 15:11:05.597537579 +0000
>>> +++ signedcommit4_sha1_expected 2024-07-03 15:11:05.553537766 +0000
>>> @@ -1 +1 @@
>>> -9179ccc5b15588bc3a45c5cc75bdec380f8ccb86
>>> +c6c46f92bc2cfda57ad6bf7981fa654825376b24
>>> error: last command exited with $?=1
>>> not ok 173 - Verify commit signedcommit4's sha1 oid
>>> #
>>> # git --git-dir=repo-sha256/.git rev-parse --output-object-format=sha1 ${sha256_oid} > ${name}_sha1 &&
>>> # test_cmp ${name}_sha1 ${name}_sha1_expected
>>> #
>>>
>>> This seems like it's just exposing a pre-existing failure,
>>> as I can't imagine how creating GNUPGHOME would cause the
>>> actual and expected SHA's to differ. :)Hmm. Let me see.
The test goes through and creates 2 repositories, one sha1 and the other sha256.
In those repositories a gpg signed commit is created. That gpg signed commit should contain both the signed sha1 and the signed sha256 gpg signatures. As both object-format and compat-object-format are set in the config.
Then the commit is extracted and one of the signatures removed.
Then the oid of the signed commit with only a single signed gpg signature is computed.
In the sha256 repository the sha256 oid is given to get the sha1 oid.
That sha1 oid is of the signed gpg commit is compared with the previously computed sha1 oid.
So I think a messed up GNUPGHOME could result in the wrong signing key being used. Though how that signing key could be inconsistent from one part of the test to the other I don't know.
Not seeing t/t1016/gpg as the gpg program does look like a more likely cause of the error there.
Show 26 quoted lines
>>>
>>> Perhaps the intended gpg wrapper script which sets
>>> `--faked-system-time` isn't being used?
>>>
>>> I'm not sure why that would differ in the Github actions
>>> from my local builds, but I don't know what else differs in
>>> the Ubuntu images and/or environment used by the actions.
>>
>> I have run a good number of builds with the patches applied
>> and t1016-compatObjectFormat regularly fails for all of the
>> tests which use the GPG2 prereq. A recent Github CI run is
>> here:
>>
>> https://github.com/tmzullinger/git/actions/runs/13570544425
>>
>> I think this test flakiness should be fixed so that we can
>> apply the patch to fix the GPG2 prereq. As it is, we're
>> skipping _all_ of the tests which require GPG2.
>
> Any progress or responses? All of these tests, that nobody seemed
> to have caught breakage of because they weren't being run anyway,
> seem to be flakey with the new GNUPGHOME set-up.
>
> I am tempted to do this in the meantime, but I'd really prefer not
> to have to do so, assuming that these tests, when fixed, would be
> materially contributing to the health of our codebase.
I just dug into this a little and hopefully I have paged enough state back to understand this.
In my testing a missing GNUPGHOME appears enough to prevent the prerequisite from succeeding. So let's fix that. Todd Zullinger's sent some nice patches to do that (up-thread), or you can take use my minimal version.
The only possible source of flakiness in the tests I can see is the possibility of t/t1016/gpg not getting called (which uses a fixed timestamp). It appears you just fixed that problem in commit 516bf45749bb ("t1016: make sure to use specified GPG").
With that commit reverted I can reproduce the flakiness locally by just running the test manually a few times.
I believe I used the GPG2 prereq because I don't have the older version of GPG to test with. So I don't know if t1016 would work on the older version of GPG or not.
Show changes to t/lib-gpg.sh +2 −0
diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh
index 937b876bd052..c4bbedfe081e 100644
--- a/t/lib-gpg.sh
+++ b/t/lib-gpg.sh
@@ -62,6 +62,8 @@ test_lazy_prereq GPG2 '
exit 1
;;
*)
+ mkdir "$GNUPGHOME" &&
+ chmod 0700 "$GNUPGHOME" &&
(gpgconf --kill all || : ) &&
gpg --homedir "${GNUPGHOME}" --import \
"$TEST_DIRECTORY"/lib-gpg/keyring.gpg &&
Eric