From: Jeff King <peff@peff.net>
To: "Randall S. Becker" <rsbecker@nexbridge.com>
Cc: 'Junio C Hamano' <gitster@pobox.com>,
git@vger.kernel.org, git-packagers@googlegroups.com
Subject: Re: [ANNOUNCE] Git v2.26.0 - Test Results NonStop Platform
Date: Mon, 23 Mar 2020 23:52:16 -0400 [thread overview]
Message-ID: <20200324035216.GB51305@coredump.intra.peff.net> (raw)
In-Reply-To: <02d901d60159$94b3b250$be1b16f0$@nexbridge.com>
On Mon, Mar 23, 2020 at 05:25:25PM -0400, Randall S. Becker wrote:
> On March 22, 2020 9:10 PM, Junio C Hamano wrote:
> > The latest feature release Git v2.26.0 is now available at the usual places. It
> > is comprised of 504 non-merge commits since v2.25.0, contributed by 64
> > people, 12 of which are new faces.
>
> We had t0301 fail again. This is run entirely within bash as we gave
> up on ksh. I need some advice on what to do here. It does look like
> this is actually in git rather than the tests, based on below.
>
> What is really strange is that the subtests are transiently failing
> and not the same test each time. I cannot get any consistency during
> test runs. I also do not see anything in the differences that might
> account for this, unless somehow the unicode length. I did revert and
> retried the test, which also resulted in transient failures. It all
> works fine when I use -x, so I can't shed light on it from there. An
> example of the failure is:
t0301 is about credential-cache, which involves daemonizing a process
and talking to it over a unix socket. I could very well believe that
there is some portability weirdness there on an exotic platform.
In particular:
> --- expect-stdout 2020-03-23 20:40:57 +0000
> +++ stdout 2020-03-23 20:40:58 +0000
> @@ -1,4 +1,4 @@
> protocol=https
> host=example.com
> -username=askpass-username
> -password=askpass-password
> +username=store-user
> +password=store-pass
> not ok 21 - helper (cache) can forget host
The point of that test is to tell the cache daemon to throw away the
entry, which means the next "fill" should have to resort to askpass. But
clearly it doesn't.
The "forgetting" is all internal to the daemon, so I don't think we'd
have a bug there. But is it possible that the client wasn't able to
contact the daemon? It would consider that a success (if there is no
daemon, then everything is already forgotten). If that happens
intermittently (when there actually _is_ a cache daemon there), it would
explain the behavior you're seeing.
Maybe try a patch like this:
diff --git a/credential-cache.c b/credential-cache.c
index 1cccc3a0b9..26baf74332 100644
--- a/credential-cache.c
+++ b/credential-cache.c
@@ -78,6 +78,8 @@ static void do_cache(const char *socket, const char *action, int timeout,
spawn_daemon(socket);
if (send_request(socket, &buf) < 0)
die_errno("unable to connect to cache daemon");
+ } else {
+ die_errno("cache daemon not available");
}
}
strbuf_release(&buf);
That will cause tests 1 and 14 of t0301 to fail consistently, but
possibly it could shed some light if other tests fail with it, too.
-Peff
next prev parent reply other threads:[~2020-03-24 3:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-23 21:25 [ANNOUNCE] Git v2.26.0 - Test Results NonStop Platform Randall S. Becker
2020-03-24 3:52 ` Jeff King [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-03-24 18:37 Randall S. Becker
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200324035216.GB51305@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git-packagers@googlegroups.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=rsbecker@nexbridge.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).