[makubacki]

Description

Status: FCP

Proposes using cargo-nextest for running tests in Patina.

• Impacts functionality?
• Impacts security?
• Breaking change?
• Includes tests?
• Includes documentation?

How This Was Tested

• N/A

Integration Instructions

• N/A

[patina-automation]

✅ QEMU Validation Passed

All QEMU validation jobs completed successfully.

Note: Q35 is only built on Windows hosts (QEMU boot is disabled due to a QEMU vfat issue).

Workflow run: https://github.com/OpenDevicePartnership/patina/actions/runs/32272820342

Boot Time to EFI Shell

Platform	Elapsed
ArmVirt (Linux Host)	24.1s
Q35 (Linux Host)	29.0s

Dependencies

Repository	Ref
patina	2364571
patina-dxe-core-qemu	5c12f1a
patina-fw-patcher	d06ba7e
patina-qemu firmware	v4.0.5
patina-qemu build script	c1946d7

This comment was automatically generated by the Patina QEMU PR Validation Post workflow.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[os-d]

imo, the only feature we were trying to get with #[serial] is resolved by cargo-nextest's isolation and I would converge on cargo-nextest to keep it simpler.

The other thing to note is that miri supports cargo-nextest, so there are the same benefits to running miri with nextest instead of cargo-test and timing on miri matters even more because it is so slow. However, it is almost certain that miri's own runtime is going to far overshadow the test harness time; I don't have data on if nextest helps significantly in overall miri time.

[makubacki]

imo, the only feature we were trying to get with #[serial] is resolved by cargo-nextest's isolation and I would converge on cargo-nextest to keep it simpler.

I haven't looked thoroughly, but I agree that I think we can drop them all.

The other thing to note is that miri supports cargo-nextest, so there are the same benefits to running miri with nextest instead of cargo-test and timing on miri matters even more because it is so slow. However, it is almost certain that miri's own runtime is going to far overshadow the test harness time; I don't have data on if nextest helps significantly in overall miri time.

I'll look into this a bit more and add some miri info to the RFC.

[makubacki]

I'll look into this a bit more and add some miri info to the RFC.

Done and pushed.

[makubacki]

Note: The RFC has entered Final Comment Period (FCP).

[cfernald]

I agree. It seems if we aren't regularly exercising the correctness of serializiation or locking in tests in CI, then it will just start to fail and will be a burden to fix them up all the time. Better to drop it and only support nextext. Will be a bit annoying to no longer expect cargo test within a crate to not hit concurrency issues, though I guess that is solved with cargo test --test-threads=1

[makubacki]

Note: Moved to FCP on Aug 11. Planning to merge this week.