Subject: Re: [PATCH] ci: install P4 from package to fix build error

From: SZEDER Gábor <[email-masked]>
Date: Thu, 12 Sep 2019 13:09:55 +0200

On Wed, Sep 11, 2019 at 05:12:31PM +0200, Johannes Schindelin wrote:
> On Tue, 10 Sep 2019, SZEDER Gábor wrote:
> 
> > On Tue, Sep 10, 2019 at 12:51:01AM +0200, Johannes Schindelin wrote:
> > > On Fri, 6 Sep 2019, SZEDER Gábor wrote:
> > >
> > > > On Fri, Sep 06, 2019 at 12:27:11PM +0200, SZEDER Gábor wrote:
> >
> > > > > Let's install P4 from the package repository, because this
> > > > > approach seems to be simpler and more future proof.
> > > > >
> > > > > Note that we used to install an old P4 version (2016.2) in the
> > > > > Linux build jobs, but with this change we'll install the most
> > > > > recent version available in the Perforce package repository
> > > > > (currently 2019.1).
> > > >
> > > > So I'm not quite sure whether we really want this patch.  It
> > > > depends on how important it is to test 'git-p4' with an old P4
> > > > version, but I don't really have an opinion on that.
> > >
> > > I'd rather have that patch. It seems to be a much better idea to use
> > > the package management system than to rely on one host, especially
> > > when said host already displayed hiccups.
> >
> > Well, I'm not so sure.  As far as I remember this was the first time
> > that this Perforce filehost was inaccessible and a simple "Restart
> > job" could not rectify the situation, because it was inaccessible for
> > about a day or more.
> 
> Right.
> 
> > OTOH, transient errors or timeouts from 'apt-get update' or 'install'
> > from the official Ubuntu package repositories are not uncommon (at
> > least on Travis CI), although in those cases it's usually enough to
> > just restart the errored job.
> 
> My impression precisely. I trust the Ubuntu package servers to have
> transient, _short-lived_ problems ;-)

Heh, that's true, but note that we won't install P4 from the Ubuntu
package servers, but from the Perforce package repository, so I doubt
we can expect any improvements in this regard.

OTOH, instead of issuing only two HTTP requests to download those two
binaries we'll issue a total of 9 requests (1 pubkey, 2 package lists,
6 packages) that could go wrong.

I'm undecided, and at the very least the proposed commit message
should be updated.