Open DanielJoyce opened 1 year ago
This sounds like a relatively simple thing to implement—though I say this without having looked at the source code. Is the reason it has been delayed for so long that few people actually care about it, or do the maintainers disapprove of the change?
If it's the latter, it could be put behind a "nextest" feature flag.
Currently using cargo nextest run --retries 1
as a workaround to this, but the tests that initially failed will be reported as flaky.
Unfortunately cargo nextest run --retries 1
is not deterministic and thus not stable for any use in CI ...
Some discussion in https://github.com/launchbadge/sqlx/pull/2640#issuecomment-1659455042
Since #2640 is merged is there any progress on this Issue?
Is your feature request related to a problem? Please describe. Currently running tests annotated with #[sqlx::test] fail with nextest because of how sqlx sets up test dbs, and nextest starts multiple test binaries in parallel to speed up tests
Nextest has real nice reporting features.
Describe the solution you'd like I can use #[sqlx::test] with nextest
Describe alternatives you've considered None, because the test binary that has a #[sqlx::test] in it deletes the db on exit, stomping on the next invocation of the binary by nextest