Re: What's cooking in git.git (Jan 2020, #04; Wed, 22)

> Hi Gábor,
> 
> On Thu, 6 Feb 2020, SZEDER Gábor wrote:
> 
> > On Wed, Feb 05, 2020 at 01:01:50PM -0800, Junio C Hamano wrote:
> > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > >
> > > >> Do they have to shout that loudly in the name?
> > > >>
> > > >> We could rename these jobs to e.g. 'linux-clang-py2' and the like, but
> > > >> I think it would bring little benefit, if any.  In our Travis CI
> > > >> builds these Linux/OSX Clang/GCC jobs come from the build matrix,
> > > >> therefore the jobname is not visible on the Travis CI web interface or
> > > >> API, only in the build logs.  There are some pages on Azure Pipelines
> > > >> that do show the jobname (and some that could, but hide it instead),
> > > >> but it's just too convoluted (or sometimes even impossible, well, for
> > > >> me anyway) to get there.
> > > >>
> > > >> And if the requested Python binary can't be found, which will
> > > >> eventually happen with 'python2', then the non-zero exit code of
> > > >> 'which' will abort the build, no matter how the job is called.
> > > >
> > > > I am mostly worried about contributors whose PRs break for "magic"
> > > > reasons. If it is not clear where the difference between `linux-gcc` and
> > > > `linux-clang` lies, that can cause unintended frustration, and I do not
> > > > want to cause that.
> >
> > I'm not worried about that.  If a contributor doesn't touch any of our
> > Python scripts, then I don't see why using a different Python version
> > in the build would cause any issues.  And if they do modify one of the
> > Python scripts, then they should make sure that their modifications
> > work both with Python 2 and 3 in the first place.
> 
> If the frequent problems with downloading the Perforce binariers taught me
> anything, it is that the most likely explanation for failures in the
> linux-gcc job is that Perforce, once again, updated their binaries,
> uploaded them _to the exact same URL as before_, and that there is nothing
> wrong in the PR or the patches.
> 
> That _is_ the most likely explanation, given our record.
> 
> So what are contributors supposed to do with that? Nothing in the name
> `linux-gcc` cries out loud: Hey, this is a Homebrew problem, there is most

> > > So, what, if any, decision have we reached?
> > >
> > > If linux-gcc and linux-clang labels are not visible, linux-clang-py2
> > > and osx-py3 would not be, either, so...
> >
> > The 'linux-gcc' and 'linux-clang' labels are not visible on Travis CI,
> > because those jobs as part of the build matrix, and, consequently, we
> > can't set the a 'jobname' environment variable for them in
> > '.travis.yml'.  If we were to include additional jobs for the Python
> > scripts, then for those we can (and should!) set
> > 'jobname=linux-python' or something, and that would be visible on the
> > Travis CI web interface, just like e.g. 'jobname=StaticAnalysis'.
> 
> I think we can see that jobname very well, though. If you direct your web
> browser to
> https://travis-ci.org/git/git/builds/646646192?utm_source=github_status&utm_medium=notification
> you will see something like this:
> 
>     Build jobs		View config
> 
> ! 5281.1 AMD64		Compiler: clang Xcode: xcode10.1 C	no environment variables set	8 min 20 sec
> ! 5281.2 AMD64		Compiler: gcc Xcode: xcode10.1 C	no environment variables set	8 min 23 sec
> X 5281.3 AMD64		Compiler: clang Xcode: xcode10.1 C	no environment variables set	1 min 57 sec
> X 5281.4 AMD64		Compiler: gcc Xcode: xcode10.1 C	no environment variables set	2 min 41 sec
> ! 5281.5 AMD64		Xcode: xcode10.1 C			jobname=GIT_TEST_GETTEXT_POISON	5 min 14 sec
> X 5281.6 AMD64		Xcode: xcode10.1 C			jobname=linux-gcc-4.8		1 min 13 sec
> ! 5281.7 AMD64		Xcode: xcode10.1 C			jobname=Linux32			6 min 50 sec
> ✓ 5281.8 AMD64		Xcode: xcode10.1 C			jobname=StaticAnalysis		10 min 56 sec
> ✓ 5281.9 AMD64		Xcode: xcode10.1 C			jobname=Documentation		6 min 15 sec