patch, 3 partsreduce test suite dependency on network

I'm in a remote cabin with spotty internet this week, and I noticed several delays while running "make test". The culprit was DNS request packets being dropped due to a passing rainstorm, but not enough that the OS decided the network was down (the DNS resolver was on the other end of a VPN). So I was waiting for DNS timeouts.

This is kind of an exotic situation, but it seems to me that the test suite should avoid making network requests in general, just for the sake of reproducibility. And avoiding timeouts is a nice bonus.

So here are a few small fixes, after which running "make test" requires zero DNS lookups (and presumably zero external network at all, though of course we hit localhost/127.0.0.1 for various http, etc, tests).

  [1/3]: t5553: use local url for invalid fetch
  [2/3]: t5551: do not confirm that bogus url cannot be used
  [3/3]: t/lib-bundle-uri: use local fake bundle URLs

 t/lib-bundle-uri-protocol.sh | 4 ++--
 t/t5551-http-fetch-smart.sh  | 1 -
 t/t5553-set-upstream.sh      | 8 ++++----
 3 files changed, 6 insertions(+), 7 deletions(-)

-Peff

We test how "fetch --set-upstream" behaves when given an invalid URL, using the bogus URL "http://nosuchdomain.example.com". But finding out that it is invalid requires an actual DNS lookup.

Reduce our dependency on external factors by using an invalid local filesystem URL, which works just as well for our purposes.

Signed-off-by: Jeff King <peff@peff.net>
---
 t/t5553-set-upstream.sh | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

t5551 tries to access a URL with a bogus hostname and confirms that http.curloptResolve lets us use this otherwise unresolvable name.

Before doing so, though, we confirm that trying to access the bogus hostname without http.curloptResolve fails as expected. This isn't testing Git at all, but is confirming the test's assumptions. That's often a good thing to do, but in this case it means that we'll actually try to resolve the external name. Even though it's unlikely that "gitbogusexamplehost.invalid" would ever resolve, the DNS lookup itself may take time.

It's probably reasonable to just assume that this obviously-bogus name would not actually resolve in practice, which lets us reduce our test suite's dependency on the outside world.

Signed-off-by: Jeff King <peff@peff.net>
---
 t/t5551-http-fetch-smart.sh | 1 -
 1 file changed, 1 deletion(-)

A few of the bundle URI tests point config at a fake bundle; they care only that the client has been configured with _some_ bundle, but it doesn't have to actually contain objects.

For the file:// tests, we use "$BUNDLE_URI_REPO_URI/fake.bdl", a non-existent file inside the actual remote repo. But for git:// and http:// tests, we use "https://example.com/fake.bdl". This works OK in practice, but it means we actually make a request to example.com (which returns a placeholder HTML response). That can be annoying when running the test suite on a spotty network (it doesn't produce a wrong result, since we expect it to fail, but it may introduce delays).

We can reduce our dependency on the outside world by using a local URL. It would work to just do "file://$PWD/fake.bdl" here, since the bundle code does not care about the actual location. But in the long run I suspect we may have more restrictions on which protocols can be passed around as bundle URIs. So instead, let's stick with the file:// repo's pattern and just point to a bogus name based on the remote repo's URL.

For http this makes perfect sense; we'll make a request to the local http server and find that there's nothing there. For git:// it's a little weird, as you wouldn't normally access a bundle file over git:// at all. But it's probably the most reasonable guess we can make for now, and anybody who tightens protocol selection later will know better what's the best path forward.

Signed-off-by: Jeff King <peff@peff.net>
---
 t/lib-bundle-uri-protocol.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)