I don't know if we want this. @christopherfujino suggested it and it seemed like an interesting thing to try implementing while I waited for CI to run on my other PR. :-)

I don't know if we want this. @christopherfujino suggested it and it seemed like an interesting thing to try implementing while I waited for CI to run on my other PR. :-)

Oh, this would also help the situation where I have 4 analysis failures, and I have to push 4 separate commits.

Oh, this would also help the situation where I have 4 analysis failures, and I have to push 4 separate commits.

If I understood this correctly, it also means that when running tests in CI/CD, it won't fail until it runs all tests, right? If that is true then I would prefer to guard it under a flag as it would cost some $$$ due to the runtime.

I usually run the tests mannually when the first attempt fails to avoid multiple commits.

Oh, this would also help the situation where I have 4 analysis failures, and I have to push 4 separate commits.

If I understood this correctly, it also means that when running tests in CI/CD, it won't fail until it runs all tests, right? If that is true then I would prefer to guard it under a flag as it would cost some $$$ due to the runtime.

I usually run the tests mannually when the first attempt fails to avoid multiple commits.

are you running the framework internal test suite on your own CI/CD?

The vast majority of runs on CI pass all the tests, so the few $$$ you would save from aborting early when it fails early is probably a trivial amount. Also on CI generally much of this is run in parallel anyway, so it's not like it actually reduces it that much on CI even if something fails.

@pedromassango That said, I'll add a flag to my follow-up PR to make it abort on the first error.

I'm going to land this and see what happens.

are you running the framework internal test suite on your own CI/CD?

No. I think I misunderstood this PR

FWIW I am adding --abort-on-error for test.dart, in #109206