Re: [PATCH v3] http: do not ignore proxy path
- From
Jeff King <peff@peff.net>
- Date
- Aug 1, 2024, 05:45 UTC
- Message-ID
- <20240801054523.GA621899@coredump.intra.peff.net>
- In-Reply-To
- <xmqqle1hyzcu.fsf@gitster.g>
On Wed, Jul 31, 2024 at 03:24:01PM -0700, Junio C Hamano wrote:
Show 30 quoted lines
> > +start_socks() {
> > + mkfifo socks_output &&
> > + {
> > + "$PERL_PATH" "$TEST_DIRECTORY/socks4-proxy.pl" "$1" >socks_output &
> > + socks_pid=$!
> > + } &&
> > + read line <socks_output &&
> > + test "$line" = ready
> > +}
> > +
> > +test_expect_success PERL 'try to start SOCKS proxy' '
> > + # The %30 tests that the correct amount of percent-encoding is applied
> > + # to the proxy string passed to curl.
> > + if start_socks %30.sock
> > + then
> > + test_set_prereq SOCKS_PROXY
> > + fi
> > +'
>
> Making it a regular test_expect_success would mean GIT_SKIP_TEST
> mechansim can be used to skip it, which is probably not what you
> want. Can't this be a more common test_lazy_prereq, perhaps like
>
> test_lazy_prereq SOCKS_PROXY '
> # useful comment about 30% here ...
> test_have_prereq PERL &&
> start_socks %30.sock
> '
>
> or something?I think Ryan picked up this approach from my earlier mail. And the reason I suggested doing it this way is that the prereq test has an important side effect: it creates the socket and starts the proxy server!
I think lazy prereqs only make sense when their only output is the yes/no of whether we match the prereq. And then we don't care when or how often they are evaluated. I do think things would work, assuming the proxy server then can serve multiple tests. It just feels weird, and doing it more like the git-daemon/http tests made more sense to me (though those ones do not even do their work inside an expect block).
If we did it in a lazy prereq I think you'd need to munge the path, as the lazy prereq operates in a throwaway directory (so the %30.sock would get removed before we can use it in the next test).
-Peff