From: Junio C Hamano <hidden> Date: 2021-01-15 03:15:37
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 <redacted>
---
ci/install-dependencies.sh | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
From: Jeff King <hidden> Date: 2021-01-15 20:00:21
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.
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.
-Peff
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 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, and it looks like logs get expired after a few
months anyway.
-Peff
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,
I keep an eye out for flaky test failures, because they are much more
entertaining to hunt down than the "usual" bugs, but can't recall any
involving Perforce in the last year, since 6026aff5bb (git-p4: cleanup
better on error exit, 2020-01-29) fixed the last one I knew about.
and it looks like logs get expired after a few
months anyway.
From: Philippe Blain <hidden> Date: 2021-01-24 02:42:31
Hi everyone,
Le 2021-01-15 à 14:59, Jeff King a écrit :
On Thu, Jan 14, 2021 at 07:14:34PM -0800, Junio C Hamano wrote:
quoted
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:
~~~
From: Taylor Blau <hidden> Date: 2021-01-25 00:57:37
On Sat, Jan 23, 2021 at 09:41:29PM -0500, Philippe Blain wrote:
I've CC-ed Dscho regarding if we also want this for the Windows tests,
(I don't see why not) and if we feel it's a good idea I can
send a proper patch.
:-). The first thought I had when I read your email was: "shouldn't we
turn this on in those sharded Windows tests, too?"
So, yeah, I think that this is a good idea for the windows- and
vs-build tests, too.
Thanks,
Taylor
From: Jeff King <hidden> Date: 2021-01-27 23:22:53
On Sat, Jan 23, 2021 at 09:41:29PM -0500, Philippe Blain wrote:
quoted
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:
Thanks, that's exactly what I think we'd want.
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.
- we already have the Windows tests in a separate matrix anyway, so a
failure on Linux would run the whole Windows suite (which is an
order of magnitude more expensive)
- even within the Windows matrix, I think running the rest of the
tests after a failure is still valuable. If there's a second
failure, you save a round-trip to CI (so it doesn't reduce CPU, but
it may help latency to reach a passing state).
-Peff