Re: [PATCH v2 1/3] CI: run "brew install perforce" without past workarounds

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Apr 22 2022, Carlo Arenas wrote:

> On Fri, Apr 22, 2022 at 2:07 AM Ævar Arnfjörð Bjarmason
> <avarab@xxxxxxxxx> wrote:
>> diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
>> index dbcebad2fb2..82fa87f97af 100755
>> --- a/ci/install-dependencies.sh
>> +++ b/ci/install-dependencies.sh
>> @@ -37,13 +37,7 @@ 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
>> +       brew install perforce
>
> While this might work under the current VM configuration used by
> github actions, is definitely not the usual configuration in macOS
> installations and therefore likely to break if run locally (as some
> other on the fly changes attempt to suggest)
>
> keeping the "--no-quarantine" makes for a less likely to fail option
> (since SIP is enabled by default), and therefore I am also concerned
> that by removing all these other (learned the hard way) workarounds we
> might be making this more fragile for the future as well.

It works with the current CI, and keeping those fallbacks would have
meant turning this into some for-loop where we track which command
variant failed exactly, then retrying that with the SHA-256 munging.

> instead of this rewrite of the brew interface logic, removing brew as
> you suggested would be probably better.

I won't have time to pursue that in the near future, sorry. Especially
as I've got no OSX box, so any changes to this series mean long painful
bouncing around against the GitHub CI.

Anyway. I'd be happy for you to pick this up, whether that means
re-rolling my series with your suggested changes or taking yours over
mine I really don't care, I just want to not see those OSX CI errors
anymore.

As noted I have a mild preference out of general principle of having the
CI at least somewhat deterministic, i.e. to do this series where if we
can't get p4 at all we'll fail.

But I'd be fine either way, i.e. your series is also fine by
me. Whatever stops these errors from happening whenever perforce.com
updates the packages & the brew recipes haven't been bumped yet...

Thanks!




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux