Re: Travis not looking so good

[Taylor Blau <me@ttaylorr.com>]

Hi Gábor,

On Sun, Jun 02, 2019 at 01:22:39PM +0200, SZEDER Gábor wrote:
> On Sat, Jun 01, 2019 at 12:41:43AM +0000, brian m. carlson wrote:
> > On 2019-05-30 at 19:32:41, Johannes Schindelin wrote:
> > > Hi Gábor,
> > >
> > > do you have any idea why Travis is failing like this in the macOS/gcc
> > > job?
> > >
> > > > +case "$jobname" in
> > > > +brew link gcc@8
> > > > Error: No such keg: /usr/local/Cellar/gcc@8
> > > > The command "ci/install-dependencies.sh" failed and exited with 1 during .
> > >
> > > I usually only look at the Azure Pipelines (which gives me plenty enough
> > > to do, what with pu's individual branches being tested individually), but
> > > couldn't fail to notice that *all* four branches (maint, master, next and
> > > pu) fail in Travis' macOS/gcc job (and only there, the Azure Pipelines are
> > > all green):
> > >
> > > https://github.com/git/git/branches/all
> > >
> > > What's going on?
>
> The usual: Homebrew desperately tries to be overly clever and helpful,
> but ends up being dumb and annoying. :)
>
> I was hoping that this issue will just solve itself, like several
> other brew breakages in the past, but apparently it won't...

I have noticed this as well on my own fork's TravisCI builds.

> > I suspect if we want to use GCC 8, we need to explicitly install it by
> > using "brew install gcc@8", or we can just pick the latest released GCC
> > by using "brew install gcc" if we like that better. We will still need
> > to do "brew link gcc" (or "gcc@8"), since I suspect Homebrew won't
> > auto-link it since macOS provides a gcc binary.
>
> Yeah, installing gcc@8 or gcc works.  Back in 2c8921db2b (travis-ci:
> build with the right compiler, 2019-01-17) I opted for simply linking
> the already installed gcc@8 package, because GCC is big, installing it
> takes time, and the macOS build jobs have always been prone to
> exceeding the time limit.  (Note that these packages provide 'gcc-8'
> and 'gcc-9' binaries, not 'gcc', and after 'brew install'-ing them we
> won't need an additional link step (I'm not sure why linking is
> necessary with the gcc@8 package already installed in the Travis CI
> image).)

I wrote something like this up in [1] before I realized that you had
your own patches in [2]. This did fix things, but it's kind of awkward
in the sense that we're not really "installing" anything (in fact, the
patch in [1] incorrectly indicates that we are), but instead nudging it
after it discovers v8.3.


> Another possibilities are:
>
>   - Running 'brew link gcc@8' before 'brew update' works:
>
>       https://travis-ci.org/szeder/git/jobs/540027012#L139
>
>   - Not running 'brew update' at all works as well:
>
>       https://travis-ci.org/szeder/git/jobs/514960153#L179

I'd be just as happy to do something similar to what I did as really
either of these. Getting rid of 'brew update' entirely would make me
happiest, since it takes a *long* time for one of these to complete.

But, I'd almost prefer explicitly running 'brew install gcc@8' to
running 'brew link gcc@8' before 'brew update'. The later seems fragile
and awfully prone to break, especially when we are just doing it to try
and work around a Homebrew quirk.

If you don't have any plans to send your patches upstream, and feel OK
running 'brew install', let me know and I will send my patch in [1].

Thanks,
Taylor

[1]: https://github.com/ttaylorr/git/commit/a20e34d143a4a15b6b15ccb5bfb996fab9551b76
[2]: https://github.com/szeder/git/commit/ca29709d09a440d98857efb2575a3f92feaab29f