-
Notifications
You must be signed in to change notification settings - Fork 61
difftest: nextest support and speedups #334
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
base: main
Are you sure you want to change the base?
Conversation
1215a7c
to
5b43740
Compare
Even if you specify nextest filters that exclude a certain package, nextest will still build it, just not run it to discover any potential tests. I'll have to add back in the manual package excludes in CI to get back to previous CI speeds. feature request: nextest-rs/nextest#154 |
0677196
to
a861aa2
Compare
d33b067
to
d8ec881
Compare
ec23891
to
da0bb51
Compare
@LegNeato this one is ready to review, apart from the macOS difftest failing. Could you do me a favor and debug that one on your mac? It's only |
da0bb51
to
55e2ffb
Compare
55e2ffb
to
33dbe33
Compare
Pushed a fix. The problem was you were making the output directory and coming up with |
- name: cargo fetch --locked | ||
run: cargo fetch --locked --target $TARGET | ||
- name: cargo fetch --locked difftests | ||
run: cargo fetch --locked --manifest-path=tests/difftests/tests/Cargo.toml --target $TARGET | ||
- name: test difftest | ||
run: cargo test -p "difftest*" --release --no-default-features --features "use-installed-tools" | ||
- name: test difftest-runner |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My main concern here is we are making CI smarter when best practice is to make it as dumb as possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still a little unsure what to do about precompiling the tests, which is not just an CI issue but also when building from your own machine. Currently, it'll look like the tests are just stuck eating CPU for minutes, apart from the occasional slow warning from nextest, as all tests are blocked on the first test holding the target folder lock and compiling all dependencies. So at least for CI, instead of windows taking 7-8min of "nothing happening", we get cargo's compilation progress reporting.
We could move precompiling tests to the listing stage, but that would make nextest list
take forever on first execution. Not even sure if we can even print compilation progress, as when listing tests we must only write a list of tests to stdout and nothing else, otherwise nextest will error out. Though I haven't tested if piping through stderr would work.
Maybe we could alias cargo difftest
to be proceeded by a test compile before running nextest?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't that basically what we had? It ran cargo build --release
in the tests workspace regardless of what was running. The thinking was that most of the deps would be shared, but I guess I soon as I added ash
vs wgpu
that went out the window.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Crates in a workspace will compile all their dependencies into the target
dir of their workspace, regardless of where they're from. So on master, the difftest lib
crate would be compiled once in the difftest workspace's target and a second time in the root workspace's target. Now only types
is shared like that, and a lot lighter since it's just plain types and no wgpu
or ash
.
e74b17e
to
d3a1cab
Compare
|
BTW, running |
nextest has a Lines 1 to 10 in 506469f
And Line 3 in 506469f
The only problem is that nextest compiles all crates, regardless of the profile excluding the crate / package or not. So in CI and the difftest alias I use cargo's
With
In that sense, yes it is expected, since nextest needs to call the test binary to figure out which tests are contained within. Although,
|
@@ -44,15 +45,18 @@ unexpected_cfgs = { level = "allow", check-cfg = [ | |||
'cfg(target_arch, values("spirv"))' | |||
] } | |||
|
|||
# Cargo Windows bug: workspace dependencies of crates.io dependencies are resolved | |||
# incorrectly in the root workspace instead of this difftest workspace. So all | |||
# workspace dependencies here must be mirrored into the root workspace as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still don't fully understand what's causing this, I tried creating a minimal repro repo but haven't been able to. How difftest calls cargo (--manifest-path
or inherited env vars) seems to be important in the repro, as you can just cargo build
in the tests/difftest/tests
repo and it'll build just fine.
… crate `types`, massive difftest speedup 36s -> 6s
506469f
to
065dc99
Compare
Some difftest refactors of things I just want to have:
mimic-libtest
fromtester
cargo nextest run
will ignore difftestscargo difftest
will only run diffteststests/difftests/tests/target/difftest
so you can easily inspect the output instead of having to search your tmp dirrunner
crate,bin
just wraps it as a "test without harness"lib
intotests/difftests/tests
workspacetypes
crate with sharedmod config
betweenlib
andrunner
rustc_codegen_spirv
,wgpu
,ash
etc. in both workspaces, now only in difftest workspaceSpeedups