On 4/24/2023 10:59 AM, Glen Choo wrote:
> Jacob Keller <jacob.e.keller@xxxxxxxxx> writes:
>
>>> diff --git c/t/annotate-tests.sh w/t/annotate-tests.sh
>>> index 859693949b..4238ce45f8 100644
>>> --- c/t/annotate-tests.sh
>>> +++ w/t/annotate-tests.sh
>>> @@ -74,8 +74,8 @@ test_expect_success 'blame 1 author' '
>>>
>>> test_expect_success 'blame working copy' '
>>> test_when_finished "git restore file" &&
>>> - echo "1A quick brown fox jumps over" >file &&
>>> - echo "another lazy dog" >> file &&
>>> + echo "11A quick brown fox jumps over the" >file &&
>>> + echo "lazy dog" >>file &&
>>
>> I think the right fix for this test is to keep the first line (1A) the
>> same, and include the missing "the" I had removed before, and keep the
>> 2nd line as the changed line with "another lazy dog".
>
> This sounds right to me; it's easier to read when the working copy test
> and the --contents test use the same data
Yep, will have it this way in v2.
>>
>>> not ok 46 - passing hostname resolution information works
>>> #
>>> # BOGUS_HOST=gitbogusexamplehost.invalid &&
>>> # BOGUS_HTTPD_URL=$HTTPD_PROTO://$BOGUS_HOST:$LIB_HTTPD_PORT &&
>>> # test_must_fail git ls-remote "$BOGUS_HTTPD_URL/smart/repo.git" >/dev/null &&
>>> # git -c "http.curloptResolve=$BOGUS_HOST:$LIB_HTTPD_PORT:127.0.0.1" ls-remote "$BOGUS_HTTPD_URL/smart/repo.git" >/dev/null
>>> #
>>
>> I had thought this was the only failure, and that it has something to do
>> with my system configuration (possibly proxy settings) which affect
>> this.. I checked the firewall configuration and it doesn't appear to be
>> that...
>>
>> It would be nice to figure out what makes it so the tests fail so that I
>> can make sure tests properly pass on my submissions before sending them
>> in the future.
>
> I remember seeing a similar, flaky failure on an older version of master
> (~2-3 months ago). But if you based this on a recent version, I'm afraid
> I haven't seen this :/
I'm running on 667fcf4e1537 ("The tenth batch", 2023-04-17) and the
failure is consistent.
I'm not familiar with the curlopt stuff but it does seem like some sort
of environment failure..
When running with -x and -v:
> ++ git -c http.curloptResolve=gitbogusexamplehost.invalid:5551:127.0.0.1 ls-remote http://gitbogusexamplehost.invalid:5551/smart/repo.git
> fatal: unable to access 'http://gitbogusexamplehost.invalid:5551/smart/repo.git/': The requested URL returned error: 503
> error: last command exited with $?=128
It looks like this is a straight wrapper around CURLOPT_RESOLVE. It
looks like the HTTPD server starts just fine but perhaps some firewall
configuration is blocking connections.
I found I can skip the tests by setting GIT_TEST_HTTPD=no so thats a
decent workaround for me for now.
Thanks,
Jake
