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.
