patchci/install-depends: attempt to fix "brew cask" stuff

> It seems that homebrew suddenly started giving us trouble, like this:
>
> https://github.com/git/git/runs/1705953982?check_suite_focus=true#step:3:70
>
> Here is my attempt to work it around by blindly following the
> suggested course of action in the error message, without knowing
> what I am doing X-<.  I am not a Mac person.
>
> What is frustrating is that every time we hit a minor snag like this
> to break one of the jobs, all other unrelated jobs are also taken
> down.
>
> Help by those who know what they are doing on macOS would greatly be
> appreciated.  Thanks.

> ----- >8 ----- >8 ----- >8 ----- >8 ----- >8 ----- >8 -----
> We run "git pull" against "$cask_repo"; clarify that we are
> expecting not to have any of our own modifications and running "git
> pull" to merely update, by passing "--ff-only" on the command line.
>
> Also, the "brew cask install" command line triggers an error message
> that says:
>
>     Error: Calling brew cask install is disabled! Use brew install
>     [--cask] instead.
>
> In addition, "brew install caskroom/cask/perforce" step triggers an
> error that says:
>
>     Error: caskroom/cask was moved. Tap homebrew/cask instead.
>
> Attempt to see if blindly following the suggestion in these error
> messages gets us into a better shape.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  ci/install-dependencies.sh | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
> index 0229a77f7d..0b1184e04a 100755
> --- a/ci/install-dependencies.sh
> +++ b/ci/install-dependencies.sh
> @@ -44,13 +44,13 @@ osx-clang|osx-gcc)
>  	test -z "$BREW_INSTALL_PACKAGES" ||
>  	brew install $BREW_INSTALL_PACKAGES
>  	brew link --force gettext
> -	brew cask install --no-quarantine perforce || {
> +	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 &&
> -		brew cask install --no-quarantine perforce
> +		git -C "$cask_repo" pull --no-stat --ff-only &&
> +		brew install --cask --no-quarantine perforce
>  	} ||
> -	brew install caskroom/cask/perforce
> +	brew install homebrew/cask/perforce
>  	case "$jobname" in
>  	osx-gcc)
>  		brew install gcc@9

> Junio C Hamano <gitster@pobox.com> writes:
> > It seems that homebrew suddenly started giving us trouble, like this:
> > https://github.com/git/git/runs/1705953982?check_suite_focus=true#step:3:70
> >
> After seeing 'seen' with this patch at its tip pass the tests [*1*],
> I prepared a merge of this change into the tip of 'next' and
> tentatively updated 'seen' with it.
>
> The test is still running [*2*], but the problematic part in the
> macOS build has already passed, so I am planning to fast-track this
> change down to 'next', 'master' and eventually down to 'maint' to
> keep the CI going to help other platforms catch more interesting
> problems.
>
> Help from those who are more familiar with macOS and homebrew is
> still appreciated, though.

> Junio C Hamano <gitster@pobox.com> writes:
> 
>> It seems that homebrew suddenly started giving us trouble, like this:
>>
>> https://github.com/git/git/runs/1705953982?check_suite_focus=true#step:3:70
>>
>> Here is my attempt to work it around by blindly following the
>> suggested course of action in the error message, without knowing
>> what I am doing X-<.  I am not a Mac person.
>>
>> What is frustrating is that every time we hit a minor snag like this
>> to break one of the jobs, all other unrelated jobs are also taken
>> down.
>>
>> Help by those who know what they are doing on macOS would greatly be
>> appreciated.  Thanks.
> 
> After seeing 'seen' with this patch at its tip pass the tests [*1*],
> I prepared a merge of this change into the tip of 'next' and
> tentatively updated 'seen' with it.
> 
> The test is still running [*2*], but the problematic part in the
> macOS build has already passed, so I am planning to fast-track this
> change down to 'next', 'master' and eventually down to 'maint' to
> keep the CI going to help other platforms catch more interesting
> problems.
> 
> Help from those who are more familiar with macOS and homebrew is
> still appreciated, though.
> 
> 
> [References]
> 
> *1* https://github.com/git/git/actions/runs/486978562
> *2* https://github.com/git/git/runs/1706704233?check_suite_focus=true#step:3:81

> On 1/15/2021 12:48 AM, Junio C Hamano wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>> 
>>> It seems that homebrew suddenly started giving us trouble, like this:
>>>
>>> https://github.com/git/git/runs/1705953982?check_suite_focus=true#step:3:70
>>>
>>> Here is my attempt to work it around by blindly following the
>>> suggested course of action in the error message, without knowing
>>> what I am doing X-<.  I am not a Mac person.
>>>
>>> What is frustrating is that every time we hit a minor snag like this
>>> to break one of the jobs, all other unrelated jobs are also taken
>>> down.
>>>
>>> Help by those who know what they are doing on macOS would greatly be
>>> appreciated.  Thanks.
>> 
>> After seeing 'seen' with this patch at its tip pass the tests [*1*],
>> I prepared a merge of this change into the tip of 'next' and
>> tentatively updated 'seen' with it.
>> 
>> The test is still running [*2*], but the problematic part in the
>> macOS build has already passed, so I am planning to fast-track this
>> change down to 'next', 'master' and eventually down to 'maint' to
>> keep the CI going to help other platforms catch more interesting
>> problems.
>> 
>> Help from those who are more familiar with macOS and homebrew is
>> still appreciated, though.
>> 
>> 
>> [References]
>> 
>> *1* https://github.com/git/git/actions/runs/486978562
>> *2* https://github.com/git/git/runs/1706704233?check_suite_focus=true#step:3:81
>
> We recently hit this same issue with our macOS builds for Scalar
> and GCM core. Your solution looks very similar to how we fixed
> the problem.
>
> Reviewed-by: Derrick Stolee <dstolee@microsoft.com>

> It seems that homebrew suddenly started giving us trouble, like this:
> 
> https://github.com/git/git/runs/1705953982?check_suite_focus=true#step:3:70
> 
> Here is my attempt to work it around by blindly following the
> suggested course of action in the error message, without knowing
> what I am doing X-<.  I am not a Mac person.
> 
> What is frustrating is that every time we hit a minor snag like this
> to break one of the jobs, all other unrelated jobs are also taken
> down.

> > -     brew cask install --no-quarantine perforce || {
> > +     brew install --cask --no-quarantine perforce || {
>
> On a related note, it feels like perforce is a frequent offender for
> triggering spurious failures (both for homebrew setup, but I have
> definitely seen racy/flaky failures from it as well). I am tempted to
> say it is not worth the trouble, but then I do not care at all about
> git-p4 myself in the first place, so I may be biased.

> On Fri, Jan 15, 2021 at 3:00 PM Jeff King <peff@peff.net> wrote:
> > > -     brew cask install --no-quarantine perforce || {
> > > +     brew install --cask --no-quarantine perforce || {
> >
> > On a related note, it feels like perforce is a frequent offender for
> > triggering spurious failures (both for homebrew setup, but I have
> > definitely seen racy/flaky failures from it as well). I am tempted to
> > say it is not worth the trouble, but then I do not care at all about
> > git-p4 myself in the first place, so I may be biased.
> 
> To be fair to 'perforce', though, the fault of this particular problem
> is Homebrew, which doesn't seem to be all that concerned about
> backward compatibility, at least in my experience. The single
> Homebrew-related automation script I wrote for personal use has been
> broken by arbitrary Homebrew changes frustratingly often over the last
> three years.

> On Fri, Jan 15, 2021 at 03:07:38PM -0500, Eric Sunshine wrote:
> 
> > On Fri, Jan 15, 2021 at 3:00 PM Jeff King <peff@peff.net> wrote:
> > > > -     brew cask install --no-quarantine perforce || {
> > > > +     brew install --cask --no-quarantine perforce || {
> > >
> > > On a related note, it feels like perforce is a frequent offender for
> > > triggering spurious failures (both for homebrew setup, but I have
> > > definitely seen racy/flaky failures from it as well). I am tempted to
> > > say it is not worth the trouble, but then I do not care at all about
> > > git-p4 myself in the first place, so I may be biased.
> > 
> > To be fair to 'perforce', though, the fault of this particular problem
> > is Homebrew, which doesn't seem to be all that concerned about
> > backward compatibility, at least in my experience. The single
> > Homebrew-related automation script I wrote for personal use has been
> > broken by arbitrary Homebrew changes frustratingly often over the last
> > three years.
> 
> Yeah, sorry, I should have been more precise in my language. None of
> this is perforce's fault at all. It is homebrew in this case, and in the
> racy cases it is probably our tests. But I do not feel like trying to
> debug those races for a tool I don't care much about.
> 
> I tried to dig up some failing logs as an example, but it's actually a
> bit hard to search for,

> On Thu, Jan 14, 2021 at 07:14:34PM -0800, Junio C Hamano wrote:
> 
>> It seems that homebrew suddenly started giving us trouble, like this:
>>
>> https://github.com/git/git/runs/1705953982?check_suite_focus=true#step:3:70
>>
>> Here is my attempt to work it around by blindly following the
>> suggested course of action in the error message, without knowing
>> what I am doing X-<.  I am not a Mac person.
>>
>> What is frustrating is that every time we hit a minor snag like this
>> to break one of the jobs, all other unrelated jobs are also taken
>> down.
> 
> I think that has to do with the grouping in the workflow file (the
> Windows builds, for example, will cancel the _other_ Windows tests if
> they fail, but not the Linux ones).
> 
> So we could split the macos test out. It would probably involve
> duplicating a little bit of the content, but we do something similar for
> the dockerized builds. It might be that there is an option we can set to
> say "keep building the others even if one of these fails", which would
> give us the best of both.

> Yes, a quick Google search pointed me to a blog post [1]
> that mentions using 'fail-fast: false' in the test matrix so that
> one failing job does not automatically cancel the rest of the jobs
> in the matrix (the default is 'true') [2].
>
> If we apply that to all four matrices in the workflow file,
> (windows-test, vs-test, regular and dockerized), it would be
> something like this:

> > So we could split the macos test out. It would probably involve
> > duplicating a little bit of the content, but we do something similar for
> > the dockerized builds. It might be that there is an option we can set to
> > say "keep building the others even if one of these fails", which would
> > give us the best of both.
> 
> Yes, a quick Google search pointed me to a blog post [1]
> that mentions using 'fail-fast: false' in the test matrix so that
> one failing job does not automatically cancel the rest of the jobs
> in the matrix (the default is 'true') [2].
> 
> If we apply that to all four matrices in the workflow file,
> (windows-test, vs-test, regular and dockerized), it would be
> something like this:

> The downside, of course, is that a failure that will happen on every
> platform will mean wasted CPU to trigger the same failure over and over.
> But:
>
>   - I rarely see that myself, because I wouldn't bother pushing up to CI
>     until "make test" passed locally. So usually I'm finding portability
>     issues via CI. Other people might be different, though.