Re: [PATCH v3 2/4] ci: avoid brew for installing perforce

[Carlo Arenas <carenas@gmail.com>]

On Tue, Apr 26, 2022 at 8:55 AM Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> On Sat, 23 Apr 2022, Carlo Marcelo Arenas Belón wrote:
>
> > diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
> > index 41e9290fbdd..9da03350d09 100755
> > --- a/ci/install-dependencies.sh
> > +++ b/ci/install-dependencies.sh
> > @@ -37,13 +37,14 @@ macos-latest)
> >       test -z "$BREW_INSTALL_PACKAGES" ||
> >       brew install $BREW_INSTALL_PACKAGES
> >       brew link --force gettext
> > -     brew install --cask --no-quarantine perforce || {
> > -             # Update the definitions and try again
> > -             cask_repo="$(brew --repository)"/Library/Taps/homebrew/homebrew-cask &&
> > -             git -C "$cask_repo" pull --no-stat --ff-only &&
> > -             brew install --cask --no-quarantine perforce
> > -     } ||
> > -     brew install homebrew/cask/perforce
> > +     mkdir -p $HOME/bin
> > +     (
> > +             cd $HOME/bin
> > +             wget -q "https://cdist2.perforce.com/perforce/r21.2/bin.macosx1015x86_64/helix-core-server.tgz" &&
>
> I vaguely recall that Gábor Szeder attempted something similar, but I
> _think_ that ultimately there were too many moving parts in that URL that
> we did not want to hardcode.

I can see that, and indeed that is also why those series still keep
perforce installation as optional so it wouldn't block CI when it does.

BTW most of the reasons why those values are hardcoded here
is just to avoid conflicts with on the fly changes, and making it smarter
and avoiding the hardcoding would be done as a prerequisite to making
it mandatory again (if that is what is preferred)

> While I don't think that we can solve this fully, I would prefer to keep
> the existing `brew install` calls but fall back to downloading from a
> hard-coded URL.

Considering that the expectation from brew maintainers (as documented[1])
is that those mismatches would happen and should be solved manually
and that perforce releases just do inplace binary pushes I still stand by my
suggestion to avoid brew, but it might be useful as a fallback of the wget
approach if that helps with your concerns above.

> For the record, the recent problems stem from the fact that the package
> was cached on GitHub's build agents (I guess to avoid many identical
> downloads), and the cached package did not match what was recorded in the
> updated package definition. Which means that those `brew` errors are only
> transient, until a new VM image is built that caches the then-current
> perforce package.

FWIW as I updated the brew cask[2], I realized that livecheck pointed to an even
newer release, so if we are adding brew back it might be worth adding
yet another
workaround to delete the cached file and try without a SHA as Ævar suggested.

Carlo

[1] https://docs.brew.sh/Common-Issues#cask---checksum-does-not-match
[2] https://github.com/Homebrew/homebrew-cask/pull/122347