Re: [PATCH] t1404: increase core.packedRefsTimeout to avoid occasional test failure

From: SZEDER Gábor <szeder.dev@gmail.com>
Date: Aug 1, 2018, 01:37 UTC
Message-ID: <CAM0VKj=aQ1kO_i2OkkcMRJZ0a8PHVQH-oKQ1_qZ5UpxEPEK5kQ@mail.gmail.com>
In-Reply-To: <20180731233906.GB113554@aiede.svl.corp.google.com>

On Wed, Aug 1, 2018 at 1:39 AM Jonathan Nieder <jrnieder@gmail.com> wrote:

Show 9 quoted lines

> SZEDER Gábor wrote:
>
> > While 3secs timeout seems plenty, and indeed is sufficient in most
> > cases, on rare occasions it's just not quite enough: I saw this test
> > fail in Travis CI build jobs two, maybe three times because 'git
> > update-ref' timed out.
>
> I suspect these tests will fail with valgrind (just because valgrind
> makes things super slow).  Would it be safe to use timeout=-1?

I don't know. Travis CI has a time limit of about 45mins for the whole build job (including installing dependencies and compilation), and any sensible automated build system must have a similar time limit, so it would be fine to wait indefinitely in such an environment, though in case of a timeout we'd lose failure reports of failed tests, if there are any.

OTOH, my (and I guess most devs') test runs don't have such a time limit, so I'm reluctant to change it to wait indefinitely. But then again, waiting indefinitely for a lock file is not all that different from messing up something and creating an endless loop or a deadlock...