All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "SZEDER Gábor" <szeder.dev@gmail.com>, git@vger.kernel.org
Subject: Re: [RFC PATCH 4/4] t/lib-httpd: sort log based on timestamp to avoid occasional failure
Date: Fri, 15 Jun 2018 02:00:20 -0400	[thread overview]
Message-ID: <20180615060020.GA8367@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqefh94420.fsf@gitster-ct.c.googlers.com>

On Thu, Jun 14, 2018 at 11:27:03AM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> >>     Another alternative is to simply accept that these tests are racy, and
> >>     that the resulting test failures are rare enough that it isn't worth
> >>     the complexity of the workaround, but adding a comment to the affected
> >>     tests warning about the raciness is sufficient.  (But I wrote this
> >>     when I first saw and tracked down this failure; since then I observed
> >>     it four more times... :)
> >
> > It's definitely bugged me. I'd be happy to see some solution. I've been
> > close to suggesting that reading apache logs is simply not robust, and
> > we should focus our tests on the git-visible state changes (e.g., seeing
> > successful requests, updated refs, etc).
> 
> Hmph, that certainly is "checking only the things that matter",
> which is desirable.

The existing tests that look at the apache logs are very white-box, and
come from Shawn's original smart-http series. I suspect it was as much
about sanity-checking the implementation then as it was about protecting
against regressions.

So it's possible that these tests have simply outlived their usefulness.

OTOH, they might catch non-functional problems, like if we started
sending redundant requests. But then, they are not very comprehensive,
as they only cover a few basic situations (so for example, for a while
we were sending extra auth-related requests, but I don't think these
tests detected that).

-Peff

  reply	other threads:[~2018-06-15  6:00 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-14 12:31 [RFC PATCH 0/4] Fix occasional test failures in http tests SZEDER Gábor
2018-06-14 12:31 ` [PATCH 1/4] t5541: avoid empty line when truncating access log SZEDER Gábor
2018-06-14 12:31 ` [PATCH 2/4] t/lib-httpd: add the strip_access_log() helper function SZEDER Gábor
2018-06-14 12:31 ` [PATCH 3/4] t/lib-httpd: add minor and patch version to $HTTPD_VERSION SZEDER Gábor
2018-06-14 12:31 ` [RFC PATCH 4/4] t/lib-httpd: sort log based on timestamp to avoid occasional failure SZEDER Gábor
2018-06-14 16:39   ` SZEDER Gábor
2018-06-14 17:53   ` Jeff King
2018-06-14 18:27     ` Junio C Hamano
2018-06-15  6:00       ` Jeff King [this message]
2018-07-11 12:53     ` SZEDER Gábor
2018-07-11 14:45       ` Jeff King
2018-06-14 17:15 ` [RFC PATCH 0/4] Fix occasional test failures in http tests Junio C Hamano
2018-06-14 17:56 ` Jeff King
2018-07-11 12:56 ` [PATCH v2 0/3] " SZEDER Gábor
2018-07-11 12:56   ` [PATCH v2 1/3] t5541: avoid empty line when truncating access log SZEDER Gábor
2018-07-11 12:56   ` [PATCH v2 2/3] t/lib-httpd: add the strip_access_log() helper function SZEDER Gábor
2018-07-11 12:56   ` [PATCH v2 3/3] t/lib-httpd: avoid occasional failures when checking access.log SZEDER Gábor
2018-07-11 14:57     ` Jeff King
2018-07-11 17:26       ` SZEDER Gábor
2018-07-11 17:35         ` Jeff King
2018-07-11 14:58   ` [PATCH v2 0/3] Fix occasional test failures in http tests Jeff King
2018-07-12 12:22   ` [PATCH v3 " SZEDER Gábor
2018-07-12 12:22     ` [PATCH v3 1/3] t5541: clean up truncating access log SZEDER Gábor
2018-07-12 15:56       ` Jeff King
2018-07-12 12:22     ` [PATCH v3 2/3] t/lib-httpd: add the strip_access_log() helper function SZEDER Gábor
2018-07-12 12:22     ` [PATCH v3 3/3] t/lib-httpd: avoid occasional failures when checking access.log SZEDER Gábor

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=20180615060020.GA8367@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=szeder.dev@gmail.com \
    /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.