All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/16] http test bug potpourri
Date: Thu, 23 Feb 2023 15:37:05 -0800	[thread overview]
Message-ID: <xmqq8rgo3qe6.fsf@gitster.g> (raw)
In-Reply-To: Y/dEYYWKy/o96vBG@coredump.intra.peff.net

Jeff King <peff@peff.net> writes:

> So all I wanted to do was this one-liner:
>
> diff --git a/t/t5559-http-fetch-smart-http2.sh b/t/t5559-http-fetch-smart-http2.sh
> index 9eece71c2c..54aa9d3bff 100755
> --- a/t/t5559-http-fetch-smart-http2.sh
> +++ b/t/t5559-http-fetch-smart-http2.sh
> @@ -1,4 +1,5 @@
>  #!/bin/sh
>  
>  HTTP_PROTO=HTTP/2
> +LIB_HTTPD_SSL=1
>  . ./t5551-http-fetch-smart.sh
>
> but somehow I'm 16 patches deep. Let me back up.
>
> I got bit once again by the "oops, HTTP/2 tests in t5559 are sometimes
> flaky" bug. One thing that came up in earlier discussion is that HTTP/2
> over TLS should be much more reliable, because it doesn't have to go
> through the funny HTTP-upgrade path.
>
> Hence the patch above, which is also patch 16 here. And it does make the
> consistent failure of t5551.30 go away. And it even makes --stress work
> longer before a racy failure, though it still fails for me pretty
> consistently within a few dozen runs.
>
> But in doing so, I found out all sorts of neat things, like:
>
>   - when I tested with HTTP/2 and TLS before, I was accidentally not
>     using HTTP/2!
>
>   - we even have a test that should detect which version is used, but
>     it's a silent noop unless you set GIT_TEST_PROTOCOL_VERSION=0, which
>     clearly nobody does
>
>   - it turns out there are a bunch of tests which are skipped (some of
>     which even fail!) unless you set that variable
>
> So this series fixes the broken tests, adapts them to work with both v0
> and v2 Git protocol, makes them work with HTTP/2 when needed, sprinkles
> in a couple other fixes, and then finally does that one-liner.
>
> I'm actually not sure if the final patch is a good idea or not, but
> certainly all of the fixes leading up to it are worth doing.

Thanks; this must have been a lot of work.  From the "test what the
end users use, or at least something close to it" standpoint, 16/16
certainly is the right thing to do, I would think.


  parent reply	other threads:[~2023-02-23 23:37 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-23 10:48 [PATCH 0/16] http test bug potpourri Jeff King
2023-02-23 10:49 ` [PATCH 01/16] t5541: run "used receive-pack service" test earlier Jeff King
2023-02-23 10:50 ` [PATCH 02/16] t5541: stop marking "used receive-pack service" test as v0 only Jeff King
2023-02-23 10:51 ` [PATCH 03/16] t5541: simplify and move "no empty path components" test Jeff King
2023-02-23 23:36   ` Junio C Hamano
2023-02-24  2:11     ` Jeff King
2023-02-23 10:52 ` [PATCH 04/16] t5551: drop redundant grep for Accept-Language Jeff King
2023-02-23 23:36   ` Junio C Hamano
2023-02-23 10:54 ` [PATCH 05/16] t5551: lower-case headers in expected curl trace Jeff King
2023-02-23 10:56 ` [PATCH 06/16] t5551: handle HTTP/2 when checking " Jeff King
2023-02-23 10:57 ` [PATCH 07/16] t5551: stop forcing clone to run with v0 protocol Jeff King
2023-02-23 10:59 ` [PATCH 08/16] t5551: handle v2 protocol when checking curl trace Jeff King
2023-02-23 11:00 ` [PATCH 09/16] t5551: handle v2 protocol in upload-pack service test Jeff King
2023-02-23 11:01 ` [PATCH 10/16] t5551: simplify expected cookie file Jeff King
2023-02-23 11:02 ` [PATCH 11/16] t5551: handle v2 protocol in cookie test Jeff King
2023-02-23 11:05 ` [PATCH 12/16] t5551: drop curl trace lines without headers Jeff King
2023-02-23 11:05 ` [PATCH 13/16] t/lib-httpd: respect $HTTPD_PROTO in expect_askpass() Jeff King
2023-02-23 11:06 ` [PATCH 14/16] t/lib-httpd: enable HTTP/2 "h2" protocol, not just h2c Jeff King
2023-02-23 23:37   ` Junio C Hamano
2023-02-23 11:07 ` [PATCH 15/16] t5559: fix test failures with LIB_HTTPD_SSL Jeff King
2023-02-23 11:08 ` [PATCH 16/16] t5559: make SSL/TLS the default Jeff King
2023-02-23 23:37 ` Junio C Hamano [this message]
2023-02-24  2:13   ` [PATCH 0/16] http test bug potpourri Jeff King
2023-02-24  3:01     ` Junio C Hamano

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=xmqq8rgo3qe6.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.