-
Notifications
You must be signed in to change notification settings - Fork 215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Merged by Bors] - test(systest): add fail-fast for systests #6163
Conversation
I'd make it an option which we may set to |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #6163 +/- ##
=======================================
Coverage 81.8% 81.9%
=======================================
Files 302 301 -1
Lines 32630 32630
=======================================
+ Hits 26722 26731 +9
+ Misses 4174 4168 -6
+ Partials 1734 1731 -3 ☔ View full report in Codecov by Sentry. |
We do use failfast on unit tests as well, so I don't see why we shouldn't do it also for systests. |
bors try |
tryBuild succeeded: |
bors merge |
## Motivation systests appear to continue execution of all tests regardless if one of them failed.
Build failed (retrying...):
|
## Motivation systests appear to continue execution of all tests regardless if one of them failed.
Build failed: |
bors merge |
## Motivation systests appear to continue execution of all tests regardless if one of them failed.
Build failed: |
bors merge |
## Motivation systests appear to continue execution of all tests regardless if one of them failed.
Build failed: |
bors merge |
## Motivation systests appear to continue execution of all tests regardless if one of them failed.
Pull request successfully merged into develop. Build succeeded: |
Motivation
systests appear to continue execution of all tests regardless if one of them failed.
Description
This change might be debatable, because we might want to keep the configuration as is and avoid the fail-fast. One might argue that it doesn't matter if one test failed or all of them and it is better to just know earlier that the flow failed rather than having to wait for a full hour to get the signal.
If the systests weren't flaky I'd say it might be better to know which of the tests failed (maybe multiple, maybe just one out of all). But I'm not sure that right now this is actually of any use and maybe having a faster workflow is better for everyone.
Example can be seen here: https://github.com/spacemeshos/go-spacemesh/actions/runs/10014040215/job/27682907862 (look for
fail:
in the logs).Opening to discussion and happy to close this if there's resistance.
Test Plan
TODO