git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	git@vger.kernel.org
Subject: Re: Travis not looking so good
Date: Sun, 2 Jun 2019 13:22:39 +0200	[thread overview]
Message-ID: <20190602112239.GO951@szeder.dev> (raw)
In-Reply-To: <20190601004143.GN8616@genre.crustytoothpaste.net>

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'm certainly not an expert on macOS, so I could be getting things wrong
> here, but it looks like we don't ever explicitly install the gcc@8
> package from Homebrew. It may have happened to be installed
> automatically by Travis in the past, but they may have upgraded now that
> GCC 9 has been released.

gcc@8 is still installed in the Travis CI macOS image we use, but it
is version 8.2.  It's still perfectly usable, but:

When installing dependencies on macOS, we first explicitly run 'brew
update', which spends over two minutes to update itself and
information about the available packages.  This way it learns about
GCC 8.3, and after that gcc@8 refers to v8.3, and, unfortunately,
'brew' is just too dumb to be able to do anything with the still
installed 8.2 package, and the subsequent 'brew link gcc@8' fails.
But hey, even 'brew uninstall gcc@8' fails with the same error after
that, which is simply unacceptable from a package manager in my book.


> 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).)

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
  
    However, it's not as simple as removing the 'brew update' command
    from our ci script, because 'brew' is so very helpful that it
    implicitly runs update for us on the next 'brew install' anyway...
    we have to 'export HOMEBREW_NO_AUTO_UPDATE=1' first to disable
    that.

    As an additional benefit, disabling 'brew update' shaves off over
    2mins from the ~4mins currently spent on installing dependencies
    [1].

    I've been running my somewhat customized builds on Travis CI [2]
    without 'brew update' for about a month now, no ill effects yet.
    Initially I was worried that without 'brew update' a subsequent
    'brew install <pkg>' might fail, if the package repositories
    contain only a newer version of 'pkg'.  I haven't seen any such
    issues yet, and my builds can still 'brew install' Git-LFS 2.5.2
    and Perforce 18.1, although their current versions are 2.7.2 and
    19.1, respectively.


[1] And disabling the recently introduced auto cleanup feature saves
    some more time, and installing all dependencies in the macOS
    builds can be done in ~20-30secs:

      https://travis-ci.org/szeder/git/jobs/514960153#L92

[2] https://travis-ci.org/szeder/git-cooking-topics-for-travis-ci/branches

  reply	other threads:[~2019-06-02 11:22 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-30 19:32 Travis not looking so good Johannes Schindelin
2019-06-01  0:41 ` brian m. carlson
2019-06-02 11:22   ` SZEDER Gábor [this message]
2019-06-26 20:35     ` Taylor Blau
2019-06-27 13:23       ` SZEDER Gábor
2019-06-27 16:46         ` Junio C Hamano
2019-06-29 17:01           ` SZEDER Gábor
2019-07-03 10:47             ` [PATCH 1/2] ci: don't update Homebrew SZEDER Gábor
2019-07-03 10:47               ` [PATCH 2/2] ci: disable Homebrew's auto cleanup SZEDER Gábor
2019-07-03 11:49                 ` Johannes Schindelin
2019-07-03 12:26                 ` Thomas Braun
2019-07-03 13:04                   ` SZEDER Gábor
2019-07-03 16:58                     ` Junio C Hamano
2019-07-06 16:16               ` [PATCH] ci/lib.sh: update a comment about installed P4 and Git-LFS versions SZEDER Gábor
2019-07-06 16:21                 ` [PATCH v1.1] " SZEDER Gábor
2019-07-08 10:00                   ` Johannes Schindelin
2019-07-09 16:32               ` [PATCH 1/2] ci: don't update Homebrew Taylor Blau
2019-07-10 22:33                 ` Junio C Hamano

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=20190602112239.GO951@szeder.dev \
    --to=szeder.dev@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=sandals@crustytoothpaste.net \
    /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).