Looks like Chromium's crosvm (https://chromium.googlesource.com/chromiumos/platform/crosvm) just added support for running tests via #nextest! Using nextest's build reuse functionality, they were able to achieve 5-10x performance improvements in their test runs.

https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4144641?tab=comments

In the post I show how async #RustLang solves practical select problems in #Nextest, and does so in a deeply principled, composable manner. I'm really proud of it because I've taken a view that has been talked about in 1:1 messages and discussions in the past, but hasn't really been written down like this before to the best of my knowledge.

Reupping a post I wrote a few months ago: How and why #Nextest uses #RustLang #Tokio.

This post delves right into the heart of why async Rust exists: to perform *heterogenous selects*. Previous explanations have always been a bit unsatisfying for me. It's more efficient than OS threads, but is that really it? In reality, async Rust satisfies a fundamental need that no other paradigm does, which is to use tokio::select! across arbitrary async sources and platforms.

https://sunshowers.io/posts/nextest-and-tokio/

Would you find setup and teardown scripts useful for #rustlang #nextest test runs? Please upvote and comment in this issue with your use cases! Contributions and design suggestions would be welcome as well, especially if you've had practical experience with setup and teardown scripts for (e.g.) integration tests.

Please boost for reach!

https://github.com/nextest-rs/nextest/issues/683

One of the ways I disagree with many of my esteemed fellow Rust people is that I think #async #RustLang is great. Switching #nextest over to #asynchronous Rust has yielded incredible dividends, including but not limited to what I described in https://sunshowers.io/posts/nextest-and-tokio/.

The ability to write cross-platform heterogenous selects provides an extraordinary amount of power.

BTW, now that I'm at @oxidecomputer, I've been trying out nextest on #illumos and it works with zero (0) code changes!

Hi friends, if you're managing an #OpenSource or #FOSS project please tag every release you make. It's really helpful for inspecting source code and finding regressions.

#Nextest has its automated release flow be triggered by tag pushes, which means that creating and pushing tags (managed by cargo-release) is an essential part of the process. Feel free to adapt nextest's release flow to your liking!

https://github.com/nextest-rs/nextest/blob/main/.github/workflows/release.yml

https://github.com/nextest-rs/nextest/blob/main/internal-docs/releasing.md

If you're using #nextest in a corporate or controlled open-source CI environment, you could try a staged rollout. Roll this out to a percentage of users or CI jobs, then see if anything breaks. Thanks!

cargo-nextest 0.9.44 is out! A call for testing:

This version of my next-gen #RustLang #TestRunner supports pausing and resuming test runs on Unix (#NextestCtrlZ).

To make this work reliably, #nextest needs to use a "double-spawn" approach. This is currently off by default but can be turned on with an env var, `NEXTEST_EXPERIMENTAL_DOUBLE_SPAWN=1`.

Call for testing: If you're on Unix, please help test this! Update to 0.9.44, then set this environment variable. Thanks!

https://nexte.st/CHANGELOG.html#0944---2022-11-23

How good is #msys these days? The occasional times I have to use #windows for #nextest are so frustrating. cmd sucks, git bash is too basic for me.

Part 4 of my #rustlang #nextest #unix #NextestCtrlZ post is out! This one covers some really fun issues with hung processes that I ran into.

The post also introduces strace as a debugging tool on Linux.

https://cohost.org/sunshowers/post/390013-nextest-and-ctrl-z

Next post in the #rustlang #unix #nextest #NextestCtrlZ series coming tomorrow on https://cohost.org/sunshowers! Some quotes from the current draft:

"And strace just hangs as well.

*Oh no. It's spreading.*"

"So that would explain why SIGTSTP didn't work: it's a signal, which is an *interrupt*.

An immovable object meets an unstoppable force. Except the object won, and the force was stoppable after all."

@rain Thanks so much for #nextest! Just today I was benefitting from the fact that it runs every test in a separate process; such a key feature when you have to do messy things like test code in the presence of environment variables...

Over at Cohost, I've been making a series of posts about making nextest handle ctrl-z. Today's post is about *process groups*: why they exist and how nextest interacts with them.

https://cohost.org/sunshowers/post/303392-nextest-and-ctrl-z

You can find the full series of posts under Cohost's #nextest-ctrl-z tag.

#nextest #rust #unix