Optimize cargo flaky #3273
Labels
Comments
irevoire
added
maintenance
|
More additional details about this issue in the old created one: #3196 (comment) |
Merged
|
https://github.com/meilisearch/meilisearch/pull/3348/files partially fixes the issue. However, we will have to add every new sub crate to the CI, which is not convenient. Ideally, we should revert this commit and fix cargo-flaky directly. |
bors bot
added a commit
that referenced
this issue
Jan 17, 2023
3348: fix cargo flaky r=curquiza a=irevoire Partially fix #3273 Ideally, we should revert this commit and fix cargo-flaky directly to ensure we never forget to add a sub-crate to the CI. ----- Here is an example of the CI running (and thus working); https://github.com/meilisearch/meilisearch/actions/runs/3932783699/jobs/6725755801 Co-authored-by: Tamo <tamo@meilisearch.com>
|
reopening, this PR does not fix the issue totally |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, the tests appear to be flaky in our CI (tldr: they're not).
That's because
cargo-flakydoesn't handle workspaces correctly.A simple fix is to simply
cdin each sub-directory to run flaky test instead of running it at the root of the project.But the real fix should be implemented in cargo-flaky; since our use-case is pretty simple and we're our only users, it should be fairly simple to extract all the existing modules and their associated paths and see if it matches the binary we're trying to run; if it's the case, we execute the process from this path.
In the future, we should definitely look into a better way to handle this process, I'm sure we're not the first one stumbling on this kind of issue.
Also, I took a quick glance at
cargo-nextestand I must admit I did not really understand when they're changing their path before running their test, so maybe there is another way that I don't know.The text was updated successfully, but these errors were encountered: