Shard smoketests using nextest - #5705
Conversation
d362d99 to
adaad6d
Compare
| overwrite: true | ||
| retention-days: 14 | ||
|
|
||
| upload-build-artifacts-windows: |
There was a problem hiding this comment.
I think this is one place where having a new action does make sense - it would contain the upload, build, and partitions jobs, and then would be called by a smoketest-${platform} job in a matrix (like the old job)
There was a problem hiding this comment.
the yaml anchor stuff is neat but it feels a bit harder to read through and reason about
| "There is a diff in the smoketests directory." | ||
| ); | ||
| Ok(()) | ||
| } |
There was a problem hiding this comment.
nit: I don't love the duplication between run_smoketest and run_smoketest_archive - it seems like we could update one and forget to update the other. Maybe a shared function that takes at FnOnce for the actual smoketest run logic?
not a hard blocker if we just want to merge this.
There was a problem hiding this comment.
on second thought, maybe we just add a TODO for the next time we're touching this code
bfops
left a comment
bfops
left a comment
There was a problem hiding this comment.
this looks basically excellent. One preference for a refactor in the yaml and a couple of nits.
|
merging in master so that if more changes are pushed they won't hit the API rate limit issues we've been having |
2 participants
Description of Changes
Shards both the linux and windows smoketests using nextest. Each shard is executed independently from the others in its own job on its own runner. Shards can be re-run independently as well, and they don't have to rebuild anything. Not
spacetimedb-standalone, not the smoketest modules, not even the tests themselves.API and ABI breaking changes
N/A
Expected complexity level and risk
3
Testing
N/A