{"thread":{"id":"54991","subject":"[PATCH] ci/install-depends: attempt to fix \"brew cask\" stuff","startedAt":"2021-01-15T03:15:37Z","lastAt":"2021-02-01T22:12:33Z","messageCount":14,"participants":["Junio C Hamano","Eric Sunshine","Derrick Stolee","Jeff King","Philippe Blain","Taylor Blau","SZEDER Gábor"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"414424","messageId":"xmqqk0sevqlh.fsf@gitster.c.googlers.com","threadId":"54991","inReplyTo":null,"subject":"[PATCH] ci/install-depends: attempt to fix \"brew cask\" stuff","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-15T03:14:34Z","receivedAt":"2021-01-15T03:15:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"It seems that homebrew suddenly started giving us trouble, like this:\n\nhttps://github.com/git/git/runs/1705953982?check_suite_focus=true#step:3:70\n\nHere is my attempt to work it around by blindly following the\nsuggested course of action in the error message, without knowing\nwhat I am doing X-<. I am not a Mac person.\n\nWhat is frustrating is that every time we hit a minor snag like this\nto break one of the jobs, all other unrelated jobs are also taken\ndown.\n\nHelp by those who know what they are doing on macOS would greatly be\nappreciated. Thanks.\n\n----- >8 ----- >8 ----- >8 ----- >8 ----- >8 ----- >8 -----\nWe run \"git pull\" against \"$cask_repo\"; clarify that we are\nexpecting not to have any of our own modifications and running \"git\npull\" to merely update, by passing \"--ff-only\" on the command line.\n\nAlso, the \"brew cask install\" command line triggers an error message\nthat says:\n\n Error: Calling brew cask install is disabled! Use brew install\n [--cask] instead.\n\nIn addition, \"brew install caskroom/cask/perforce\" step triggers an\nerror that says:\n\n Error: caskroom/cask was moved. Tap homebrew/cask instead.\n\nAttempt to see if blindly following the suggestion in these error\nmessages gets us into a better shape.\n\nSigned-off-by: Junio C Hamano \n---\n ci/install-dependencies.sh | 8 ++++----\n 1 file changed, 4 insertions(+), 4 deletions(-)\n\ndiff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh\nindex 0229a77f7d..0b1184e04a 100755\n--- a/ci/install-dependencies.sh\n+++ b/ci/install-dependencies.sh\n@@ -44,13 +44,13 @@ osx-clang|osx-gcc)\n \ttest -z \"$BREW_INSTALL_PACKAGES\" ||\n \tbrew install $BREW_INSTALL_PACKAGES\n \tbrew link --force gettext\n-\tbrew cask install --no-quarantine perforce || {\n+\tbrew install --cask --no-quarantine perforce || {\n \t\t# Update the definitions and try again\n \t\tcask_repo=\"$(brew --repository)\"/Library/Taps/homebrew/homebrew-cask &&\n-\t\tgit -C \"$cask_repo\" pull --no-stat &&\n-\t\tbrew cask install --no-quarantine perforce\n+\t\tgit -C \"$cask_repo\" pull --no-stat --ff-only &&\n+\t\tbrew install --cask --no-quarantine perforce\n \t} ||\n-\tbrew install caskroom/cask/perforce\n+\tbrew install homebrew/cask/perforce\n \tcase \"$jobname\" in\n \tosx-gcc)\n \t\tbrew install gcc@9\n-- \n2.30.0-386-gfb533afdb4\n\n"},{"id":"414428","messageId":"xmqqa6tavjgm.fsf@gitster.c.googlers.com","threadId":"54991","inReplyTo":"xmqqk0sevqlh.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] ci/install-depends: attempt to fix \"brew cask\" stuff","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-15T05:48:41Z","receivedAt":"2021-01-15T05:49:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> It seems that homebrew suddenly started giving us trouble, like this:\n>\n> https://github.com/git/git/runs/1705953982?check_suite_focus=true#step:3:70\n>\n> Here is my attempt to work it around by blindly following the\n> suggested course of action in the error message, without knowing\n> what I am doing X-<. I am not a Mac person.\n>\n> What is frustrating is that every time we hit a minor snag like this\n> to break one of the jobs, all other unrelated jobs are also taken\n> down.\n>\n> Help by those who know what they are doing on macOS would greatly be\n> appreciated. Thanks.\n\nAfter seeing 'seen' with this patch at its tip pass the tests [*1*],\nI prepared a merge of this change into the tip of 'next' and\ntentatively updated 'seen' with it.\n\nThe test is still running [*2*], but the problematic part in the\nmacOS build has already passed, so I am planning to fast-track this\nchange down to 'next', 'master' and eventually down to 'maint' to\nkeep the CI going to help other platforms catch more interesting\nproblems.\n\nHelp from those who are more familiar with macOS and homebrew is\nstill appreciated, though.\n\n\n[References]\n\n*1* https://github.com/git/git/actions/runs/486978562\n*2* https://github.com/git/git/runs/1706704233?check_suite_focus=true#step:3:81\n\n\n> ----- >8 ----- >8 ----- >8 ----- >8 ----- >8 ----- >8 -----\n> We run \"git pull\" against \"$cask_repo\"; clarify that we are\n> expecting not to have any of our own modifications and running \"git\n> pull\" to merely update, by passing \"--ff-only\" on the command line.\n>\n> Also, the \"brew cask install\" command line triggers an error message\n> that says:\n>\n> Error: Calling brew cask install is disabled! Use brew install\n> [--cask] instead.\n>\n> In addition, \"brew install caskroom/cask/perforce\" step triggers an\n> error that says:\n>\n> Error: caskroom/cask was moved. Tap homebrew/cask instead.\n>\n> Attempt to see if blindly following the suggestion in these error\n> messages gets us into a better shape.\n>\n> Signed-off-by: Junio C Hamano \n> ---\n> ci/install-dependencies.sh | 8 ++++----\n> 1 file changed, 4 insertions(+), 4 deletions(-)\n>\n> diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh\n> index 0229a77f7d..0b1184e04a 100755\n> --- a/ci/install-dependencies.sh\n> +++ b/ci/install-dependencies.sh\n> @@ -44,13 +44,13 @@ osx-clang|osx-gcc)\n> \ttest -z \"$BREW_INSTALL_PACKAGES\" ||\n> \tbrew install $BREW_INSTALL_PACKAGES\n> \tbrew link --force gettext\n> -\tbrew cask install --no-quarantine perforce || {\n> +\tbrew install --cask --no-quarantine perforce || {\n> \t\t# Update the definitions and try again\n> \t\tcask_repo=\"$(brew --repository)\"/Library/Taps/homebrew/homebrew-cask &&\n> -\t\tgit -C \"$cask_repo\" pull --no-stat &&\n> -\t\tbrew cask install --no-quarantine perforce\n> +\t\tgit -C \"$cask_repo\" pull --no-stat --ff-only &&\n> +\t\tbrew install --cask --no-quarantine perforce\n> \t} ||\n> -\tbrew install caskroom/cask/perforce\n> +\tbrew install homebrew/cask/perforce\n> \tcase \"$jobname\" in\n> \tosx-gcc)\n> \t\tbrew install gcc@9\n"},{"id":"414430","messageId":"CAPig+cTSbwURNUEoUk8UCtVM69NuWg545zavJkyCYw8T6aG1SQ@mail.gmail.com","threadId":"54991","inReplyTo":"xmqqa6tavjgm.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] ci/install-depends: attempt to fix \"brew cask\" stuff","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2021-01-15T06:05:31Z","receivedAt":"2021-01-15T06:06:40Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, Jan 15, 2021 at 12:50 AM Junio C Hamano wrote:\n> Junio C Hamano writes:\n> > It seems that homebrew suddenly started giving us trouble, like this:\n> > https://github.com/git/git/runs/1705953982?check_suite_focus=true#step:3:70\n> >\n> After seeing 'seen' with this patch at its tip pass the tests [*1*],\n> I prepared a merge of this change into the tip of 'next' and\n> tentatively updated 'seen' with it.\n>\n> The test is still running [*2*], but the problematic part in the\n> macOS build has already passed, so I am planning to fast-track this\n> change down to 'next', 'master' and eventually down to 'maint' to\n> keep the CI going to help other platforms catch more interesting\n> problems.\n>\n> Help from those who are more familiar with macOS and homebrew is\n> still appreciated, though.\n\nI looked over your Homebrew-related changes, and they seem fine.\n\nThe `brew install homebrew/cask/perforce` command could be shortened\nto `brew install perforce`, at least at the present, but being\nexplicit with the long identifier is probably better anyhow.\n"},{"id":"414452","messageId":"19de3b73-80c6-ccea-9289-fd3f82c103ac@gmail.com","threadId":"54991","inReplyTo":"xmqqa6tavjgm.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] ci/install-depends: attempt to fix \"brew cask\" stuff","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2021-01-15T14:27:56Z","receivedAt":"2021-01-15T14:28:40Z","isPatch":true,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 1/15/2021 12:48 AM, Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n>> It seems that homebrew suddenly started giving us trouble, like this:\n>>\n>> https://github.com/git/git/runs/1705953982?check_suite_focus=true#step:3:70\n>>\n>> Here is my attempt to work it around by blindly following the\n>> suggested course of action in the error message, without knowing\n>> what I am doing X-<. I am not a Mac person.\n>>\n>> What is frustrating is that every time we hit a minor snag like this\n>> to break one of the jobs, all other unrelated jobs are also taken\n>> down.\n>>\n>> Help by those who know what they are doing on macOS would greatly be\n>> appreciated. Thanks.\n> \n> After seeing 'seen' with this patch at its tip pass the tests [*1*],\n> I prepared a merge of this change into the tip of 'next' and\n> tentatively updated 'seen' with it.\n> \n> The test is still running [*2*], but the problematic part in the\n> macOS build has already passed, so I am planning to fast-track this\n> change down to 'next', 'master' and eventually down to 'maint' to\n> keep the CI going to help other platforms catch more interesting\n> problems.\n> \n> Help from those who are more familiar with macOS and homebrew is\n> still appreciated, though.\n> \n> \n> [References]\n> \n> *1* https://github.com/git/git/actions/runs/486978562\n> *2* https://github.com/git/git/runs/1706704233?check_suite_focus=true#step:3:81\n\nWe recently hit this same issue with our macOS builds for Scalar\nand GCM core. Your solution looks very similar to how we fixed\nthe problem.\n\nReviewed-by: Derrick Stolee \n"},{"id":"414467","messageId":"xmqqpn26rn8q.fsf@gitster.c.googlers.com","threadId":"54991","inReplyTo":"19de3b73-80c6-ccea-9289-fd3f82c103ac@gmail.com","subject":"Re: [PATCH] ci/install-depends: attempt to fix \"brew cask\" stuff","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-15T19:52:53Z","receivedAt":"2021-01-15T19:53:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Derrick Stolee writes:\n\n> On 1/15/2021 12:48 AM, Junio C Hamano wrote:\n>> Junio C Hamano writes:\n>> \n>>> It seems that homebrew suddenly started giving us trouble, like this:\n>>>\n>>> https://github.com/git/git/runs/1705953982?check_suite_focus=true#step:3:70\n>>>\n>>> Here is my attempt to work it around by blindly following the\n>>> suggested course of action in the error message, without knowing\n>>> what I am doing X-<. I am not a Mac person.\n>>>\n>>> What is frustrating is that every time we hit a minor snag like this\n>>> to break one of the jobs, all other unrelated jobs are also taken\n>>> down.\n>>>\n>>> Help by those who know what they are doing on macOS would greatly be\n>>> appreciated. Thanks.\n>> \n>> After seeing 'seen' with this patch at its tip pass the tests [*1*],\n>> I prepared a merge of this change into the tip of 'next' and\n>> tentatively updated 'seen' with it.\n>> \n>> The test is still running [*2*], but the problematic part in the\n>> macOS build has already passed, so I am planning to fast-track this\n>> change down to 'next', 'master' and eventually down to 'maint' to\n>> keep the CI going to help other platforms catch more interesting\n>> problems.\n>> \n>> Help from those who are more familiar with macOS and homebrew is\n>> still appreciated, though.\n>> \n>> \n>> [References]\n>> \n>> *1* https://github.com/git/git/actions/runs/486978562\n>> *2* https://github.com/git/git/runs/1706704233?check_suite_focus=true#step:3:81\n>\n> We recently hit this same issue with our macOS builds for Scalar\n> and GCM core. Your solution looks very similar to how we fixed\n> the problem.\n>\n> Reviewed-by: Derrick Stolee \n\nThanks.\n"},{"id":"414469","messageId":"YAH0G+Y4fIxoTeZa@coredump.intra.peff.net","threadId":"54991","inReplyTo":"xmqqk0sevqlh.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] ci/install-depends: attempt to fix \"brew cask\" stuff","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-01-15T19:59:23Z","receivedAt":"2021-01-15T20:00:21Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jan 14, 2021 at 07:14:34PM -0800, Junio C Hamano wrote:\n\n> It seems that homebrew suddenly started giving us trouble, like this:\n> \n> https://github.com/git/git/runs/1705953982?check_suite_focus=true#step:3:70\n> \n> Here is my attempt to work it around by blindly following the\n> suggested course of action in the error message, without knowing\n> what I am doing X-<. I am not a Mac person.\n> \n> What is frustrating is that every time we hit a minor snag like this\n> to break one of the jobs, all other unrelated jobs are also taken\n> down.\n\nI think that has to do with the grouping in the workflow file (the\nWindows builds, for example, will cancel the _other_ Windows tests if\nthey fail, but not the Linux ones).\n\nSo we could split the macos test out. It would probably involve\nduplicating a little bit of the content, but we do something similar for\nthe dockerized builds. It might be that there is an option we can set to\nsay \"keep building the others even if one of these fails\", which would\ngive us the best of both.\n\n> \tbrew install $BREW_INSTALL_PACKAGES\n> \tbrew link --force gettext\n> -\tbrew cask install --no-quarantine perforce || {\n> +\tbrew install --cask --no-quarantine perforce || {\n\nOn a related note, it feels like perforce is a frequent offender for\ntriggering spurious failures (both for homebrew setup, but I have\ndefinitely seen racy/flaky failures from it as well). I am tempted to\nsay it is not worth the trouble, but then I do not care at all about\ngit-p4 myself in the first place, so I may be biased.\n\n-Peff\n"},{"id":"414471","messageId":"CAPig+cSWa_jgUjPXVMeOUwxQV_9Qhv0f-Wyb3odJnb1UpcOcPg@mail.gmail.com","threadId":"54991","inReplyTo":"YAH0G+Y4fIxoTeZa@coredump.intra.peff.net","subject":"Re: [PATCH] ci/install-depends: attempt to fix \"brew cask\" stuff","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2021-01-15T20:07:38Z","receivedAt":"2021-01-15T20:08:34Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, Jan 15, 2021 at 3:00 PM Jeff King wrote:\n> > - brew cask install --no-quarantine perforce || {\n> > + brew install --cask --no-quarantine perforce || {\n>\n> On a related note, it feels like perforce is a frequent offender for\n> triggering spurious failures (both for homebrew setup, but I have\n> definitely seen racy/flaky failures from it as well). I am tempted to\n> say it is not worth the trouble, but then I do not care at all about\n> git-p4 myself in the first place, so I may be biased.\n\nTo be fair to 'perforce', though, the fault of this particular problem\nis Homebrew, which doesn't seem to be all that concerned about\nbackward compatibility, at least in my experience. The single\nHomebrew-related automation script I wrote for personal use has been\nbroken by arbitrary Homebrew changes frustratingly often over the last\nthree years.\n"},{"id":"414473","messageId":"YAH/ME/YvesZBxfr@coredump.intra.peff.net","threadId":"54991","inReplyTo":"CAPig+cSWa_jgUjPXVMeOUwxQV_9Qhv0f-Wyb3odJnb1UpcOcPg@mail.gmail.com","subject":"Re: [PATCH] ci/install-depends: attempt to fix \"brew cask\" stuff","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-01-15T20:46:40Z","receivedAt":"2021-01-15T20:47:26Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 15, 2021 at 03:07:38PM -0500, Eric Sunshine wrote:\n\n> On Fri, Jan 15, 2021 at 3:00 PM Jeff King wrote:\n> > > - brew cask install --no-quarantine perforce || {\n> > > + brew install --cask --no-quarantine perforce || {\n> >\n> > On a related note, it feels like perforce is a frequent offender for\n> > triggering spurious failures (both for homebrew setup, but I have\n> > definitely seen racy/flaky failures from it as well). I am tempted to\n> > say it is not worth the trouble, but then I do not care at all about\n> > git-p4 myself in the first place, so I may be biased.\n> \n> To be fair to 'perforce', though, the fault of this particular problem\n> is Homebrew, which doesn't seem to be all that concerned about\n> backward compatibility, at least in my experience. The single\n> Homebrew-related automation script I wrote for personal use has been\n> broken by arbitrary Homebrew changes frustratingly often over the last\n> three years.\n\nYeah, sorry, I should have been more precise in my language. None of\nthis is perforce's fault at all. It is homebrew in this case, and in the\nracy cases it is probably our tests. But I do not feel like trying to\ndebug those races for a tool I don't care much about.\n\nI tried to dig up some failing logs as an example, but it's actually a\nbit hard to search for, and it looks like logs get expired after a few\nmonths anyway.\n\n-Peff\n"},{"id":"415122","messageId":"830a88ce-1728-a6a5-f60d-59328f85932c@gmail.com","threadId":"54991","inReplyTo":"YAH0G+Y4fIxoTeZa@coredump.intra.peff.net","subject":"Re: [PATCH] ci/install-depends: attempt to fix \"brew cask\" stuff","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2021-01-24T02:41:29Z","receivedAt":"2021-01-24T02:42:31Z","isPatch":true,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi everyone,\n\nLe 2021-01-15 à 14:59, Jeff King a écrit :\n> On Thu, Jan 14, 2021 at 07:14:34PM -0800, Junio C Hamano wrote:\n> \n>> It seems that homebrew suddenly started giving us trouble, like this:\n>>\n>> https://github.com/git/git/runs/1705953982?check_suite_focus=true#step:3:70\n>>\n>> Here is my attempt to work it around by blindly following the\n>> suggested course of action in the error message, without knowing\n>> what I am doing X-<. I am not a Mac person.\n>>\n>> What is frustrating is that every time we hit a minor snag like this\n>> to break one of the jobs, all other unrelated jobs are also taken\n>> down.\n> \n> I think that has to do with the grouping in the workflow file (the\n> Windows builds, for example, will cancel the _other_ Windows tests if\n> they fail, but not the Linux ones).\n> \n> So we could split the macos test out. It would probably involve\n> duplicating a little bit of the content, but we do something similar for\n> the dockerized builds. It might be that there is an option we can set to\n> say \"keep building the others even if one of these fails\", which would\n> give us the best of both.\n\nYes, a quick Google search pointed me to a blog post [1]\nthat mentions using 'fail-fast: false' in the test matrix so that\none failing job does not automatically cancel the rest of the jobs\nin the matrix (the default is 'true') [2].\n\nIf we apply that to all four matrices in the workflow file,\n(windows-test, vs-test, regular and dockerized), it would be\nsomething like this:\n\n~~~\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex aef6643648..6c31f978bc 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -125,6 +125,7 @@ jobs:\n strategy:\n matrix:\n nr: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]\n+ fail-fast: false\n steps:\n - uses: actions/checkout@v1\n - name: download build artifacts\n@@ -229,6 +230,7 @@ jobs:\n strategy:\n matrix:\n nr: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]\n+ fail-fast: false\n steps:\n - uses: actions/checkout@v1\n - name: download git-sdk-64-minimal\n@@ -289,6 +291,7 @@ jobs:\n - jobname: GETTEXT_POISON\n cc: gcc\n pool: ubuntu-latest\n+ fail-fast: false\n env:\n CC: ${{matrix.vector.cc}}\n jobname: ${{matrix.vector.jobname}}\n@@ -315,6 +318,7 @@ jobs:\n image: alpine\n - jobname: Linux32\n image: daald/ubuntu32:xenial\n+ fail-fast: false\n env:\n jobname: ${{matrix.vector.jobname}}\n runs-on: ubuntu-latest\n~~~\n\nI've CC-ed Dscho regarding if we also want this for the Windows tests,\n(I don't see why not) and if we feel it's a good idea I can\nsend a proper patch.\n\n\nCheers,\n\nPhilippe.\n\n\n[1] https://www.edwardthomson.com/blog/github_actions_6_fail_fast_matrix_workflows.html\n[2] https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstrategyfail-fast\n"},{"id":"415132","messageId":"xmqqeeia26ze.fsf@gitster.c.googlers.com","threadId":"54991","inReplyTo":"830a88ce-1728-a6a5-f60d-59328f85932c@gmail.com","subject":"Re: [PATCH] ci/install-depends: attempt to fix \"brew cask\" stuff","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-24T06:18:13Z","receivedAt":"2021-01-24T06:19:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philippe Blain writes:\n\n> Yes, a quick Google search pointed me to a blog post [1]\n> that mentions using 'fail-fast: false' in the test matrix so that\n> one failing job does not automatically cancel the rest of the jobs\n> in the matrix (the default is 'true') [2].\n>\n> If we apply that to all four matrices in the workflow file,\n> (windows-test, vs-test, regular and dockerized), it would be\n> something like this:\n\nI am assuming that \"failure of build stops tests from running\",\nwhich is done on the windows/vs-build side, is still kept with\nthis change. If that is the case, it sounds quite sensible.\n\n> I've CC-ed Dscho regarding if we also want this for the Windows tests,\n> (I don't see why not) and if we feel it's a good idea I can\n> send a proper patch.\n\nI often see windows/vs-test #4 fail first and take other 9 with it.\nWe may see some interesting patterns to emerge, when we run all of\nthem (and let all of them fail X-<).\n\nThanks for working on this.\n"},{"id":"415185","messageId":"YA4XLedWCwrnzMp7@nand.local","threadId":"54991","inReplyTo":"830a88ce-1728-a6a5-f60d-59328f85932c@gmail.com","subject":"Re: [PATCH] ci/install-depends: attempt to fix \"brew cask\" stuff","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2021-01-25T00:56:13Z","receivedAt":"2021-01-25T00:57:37Z","isPatch":true,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Sat, Jan 23, 2021 at 09:41:29PM -0500, Philippe Blain wrote:\n> I've CC-ed Dscho regarding if we also want this for the Windows tests,\n> (I don't see why not) and if we feel it's a good idea I can\n> send a proper patch.\n\n:-). The first thought I had when I read your email was: \"shouldn't we\nturn this on in those sharded Windows tests, too?\"\n\nSo, yeah, I think that this is a good idea for the windows- and\nvs-build tests, too.\n\nThanks,\nTaylor\n"},{"id":"415466","messageId":"YBHnV80bBQOxZH1O@coredump.intra.peff.net","threadId":"54991","inReplyTo":"830a88ce-1728-a6a5-f60d-59328f85932c@gmail.com","subject":"Re: [PATCH] ci/install-depends: attempt to fix \"brew cask\" stuff","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-01-27T22:21:11Z","receivedAt":"2021-01-27T23:22:53Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jan 23, 2021 at 09:41:29PM -0500, Philippe Blain wrote:\n\n> > So we could split the macos test out. It would probably involve\n> > duplicating a little bit of the content, but we do something similar for\n> > the dockerized builds. It might be that there is an option we can set to\n> > say \"keep building the others even if one of these fails\", which would\n> > give us the best of both.\n> \n> Yes, a quick Google search pointed me to a blog post [1]\n> that mentions using 'fail-fast: false' in the test matrix so that\n> one failing job does not automatically cancel the rest of the jobs\n> in the matrix (the default is 'true') [2].\n> \n> If we apply that to all four matrices in the workflow file,\n> (windows-test, vs-test, regular and dockerized), it would be\n> something like this:\n\nThanks, that's exactly what I think we'd want.\n\nThe downside, of course, is that a failure that will happen on every\nplatform will mean wasted CPU to trigger the same failure over and over.\nBut:\n\n - I rarely see that myself, because I wouldn't bother pushing up to CI\n until \"make test\" passed locally. So usually I'm finding portability\n issues via CI. Other people might be different, though.\n\n - we already have the Windows tests in a separate matrix anyway, so a\n failure on Linux would run the whole Windows suite (which is an\n order of magnitude more expensive)\n\n - even within the Windows matrix, I think running the rest of the\n tests after a failure is still valuable. If there's a second\n failure, you save a round-trip to CI (so it doesn't reduce CPU, but\n it may help latency to reach a passing state).\n\n-Peff\n"},{"id":"415477","messageId":"xmqqr1m5y6rl.fsf@gitster.c.googlers.com","threadId":"54991","inReplyTo":"YBHnV80bBQOxZH1O@coredump.intra.peff.net","subject":"Re: [PATCH] ci/install-depends: attempt to fix \"brew cask\" stuff","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-28T05:23:10Z","receivedAt":"2021-01-28T05:24:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> The downside, of course, is that a failure that will happen on every\n> platform will mean wasted CPU to trigger the same failure over and over.\n> But:\n>\n> - I rarely see that myself, because I wouldn't bother pushing up to CI\n> until \"make test\" passed locally. So usually I'm finding portability\n> issues via CI. Other people might be different, though.\n\nThis is the same for me.\n\n> - we already have the Windows tests in a separate matrix anyway, so a\n> failure on Linux would run the whole Windows suite (which is an\n> order of magnitude more expensive)\n\nBut they tend to finish earlier than OSX and Ubuntu jobs; their\nsharding of the tests into 10 jobs may probably have something to do\nwith this. \n\n> - even within the Windows matrix, I think running the rest of the\n> tests after a failure is still valuable. If there's a second\n> failure, you save a round-trip to CI (so it doesn't reduce CPU, but\n> it may help latency to reach a passing state).\n\n"},{"id":"415833","messageId":"20210201221130.GA1036595@szeder.dev","threadId":"54991","inReplyTo":"YAH/ME/YvesZBxfr@coredump.intra.peff.net","subject":"Re: [PATCH] ci/install-depends: attempt to fix \"brew cask\" stuff","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2021-02-01T22:11:30Z","receivedAt":"2021-02-01T22:12:33Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Fri, Jan 15, 2021 at 03:46:40PM -0500, Jeff King wrote:\n> On Fri, Jan 15, 2021 at 03:07:38PM -0500, Eric Sunshine wrote:\n> \n> > On Fri, Jan 15, 2021 at 3:00 PM Jeff King wrote:\n> > > > - brew cask install --no-quarantine perforce || {\n> > > > + brew install --cask --no-quarantine perforce || {\n> > >\n> > > On a related note, it feels like perforce is a frequent offender for\n> > > triggering spurious failures (both for homebrew setup, but I have\n> > > definitely seen racy/flaky failures from it as well). I am tempted to\n> > > say it is not worth the trouble, but then I do not care at all about\n> > > git-p4 myself in the first place, so I may be biased.\n> > \n> > To be fair to 'perforce', though, the fault of this particular problem\n> > is Homebrew, which doesn't seem to be all that concerned about\n> > backward compatibility, at least in my experience. The single\n> > Homebrew-related automation script I wrote for personal use has been\n> > broken by arbitrary Homebrew changes frustratingly often over the last\n> > three years.\n> \n> Yeah, sorry, I should have been more precise in my language. None of\n> this is perforce's fault at all. It is homebrew in this case, and in the\n> racy cases it is probably our tests. But I do not feel like trying to\n> debug those races for a tool I don't care much about.\n> \n> I tried to dig up some failing logs as an example, but it's actually a\n> bit hard to search for,\n\nI keep an eye out for flaky test failures, because they are much more\nentertaining to hunt down than the \"usual\" bugs, but can't recall any\ninvolving Perforce in the last year, since 6026aff5bb (git-p4: cleanup\nbetter on error exit, 2020-01-29) fixed the last one I knew about.\n\n> and it looks like logs get expired after a few\n> months anyway.\n\nTravis CI can still show our builds from mid-2016:\n\n https://travis-ci.org/github/git/git/builds/146233889\n\nthough I couldn't dig out our very first build.\n\n"}]}