From: <rsbecker@nexbridge.com>
To: <rsbecker@nexbridge.com>, "'Junio C Hamano'" <gitster@pobox.com>,
<git@vger.kernel.org>
Cc: "'Linux Kernel'" <linux-kernel@vger.kernel.org>,
<git-packagers@googlegroups.com>
Subject: RE: [Test Failures] Git v2.37.1 (was RE: [ANNOUNCE] Git v2.37.1 and others)
Date: Wed, 13 Jul 2022 22:10:39 -0400 [thread overview]
Message-ID: <021701d89726$ed4d09b0$c7e71d10$@nexbridge.com> (raw)
In-Reply-To: <01b101d896c4$31761bd0$94625370$@nexbridge.com>
On July 13, 2022 10:24 AM, I wrote:
>On July 13, 2022 8:11 AM, I wrote:
>>On July 12, 2022 1:07 PM, Junio C Hamano wrote:
>>>Git v2.37.1, together with v2.30.5, v2.31.4, v2.32.3, v2.33.4,
>>>v2.34.4, v2.35.4, and
>>>v2.36.2 for older maintenance tracks, are now available at the usual places.
>>>
>>>These are to address CVE-2022-29187, where the fixes in v2.36.1 and
>>>below to address CVE-2022-24765 released earlier may not have been
>complete.
>>
>>Following are net new test failures with 2.37.1 compared with 2.37.0
>>are as follows on NonStop ia64 and x86 platforms:
>>
>>t5516-fetch-push subtests 53, 113
>>
>>t5545-push-options subtest 9
>
>Test passes when not run in Jenkins CI/CD
>
>>t5601-clone subtest 8
>
>Test passes when not run in Jenkins CI/CD
>
>>t7502-commit-porcelain subtests 20-26, 29-33, 42-47
>
>Test passes when not run in Jenkins CI/CD
>
>>t7528-signed-commit-ssh subtests 4, 5
>
>Test passes when not run in Jenkins CI/CD
>
>So it looks like a Jenkins/git test interaction is the issue here. I'm wondering
>whether running the test with </dev/null and 2>/dev/null might make a
>difference when running in Jenkins. The tty where Jenkins was started is in a
>permanently disconnected state.
>
>Mostly ignore the subtest failures, but still, would like to know why these subtests
>in particular.
Strangely, setting stdin to /dev/null and stderr to /dev/null makes no difference in the test results. stdout is the Jenkins pipe, which is Java of course, but roughly a popen(x, "r"). I have no explanation at this point why specific tests fail - other than OpenSSH, which I know attempts to prompt if it thinks the tty is even remotely reasonable.
prev parent reply other threads:[~2022-07-14 2:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-12 17:06 [ANNOUNCE] Git v2.37.1 and others Junio C Hamano
2022-07-13 12:11 ` [Test Failures] Git v2.37.1 (was RE: [ANNOUNCE] Git v2.37.1 and others) rsbecker
2022-07-13 14:23 ` rsbecker
2022-07-14 2:10 ` rsbecker [this message]
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='021701d89726$ed4d09b0$c7e71d10$@nexbridge.com' \
--to=rsbecker@nexbridge.com \
--cc=git-packagers@googlegroups.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).