Repository navigation
Run Miri once per architecture, on the hosted runners - #1900
Merged
Merged
Conversation
jprendes
requested review from
andreiltd,
danbugs,
dblnz,
devigned,
jsturtevant,
ludfjig,
simongdavies,
squillace and
syntactically
as code owners
October 7, 2026 22:55
jprendes
added
C-enhancement
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Nightly CI still repeats Miri across eight self-hosted jobs, and daily Miri unnecessarily waits for guest builds.
2 open findings
What changed in this PR
Moves Miri testing from repeated hypervisor jobs to dedicated hosted runners.
Changes:
- Adds a reusable architecture-specific Miri workflow.
- Removes Miri from the build-test matrix.
- Installs the pinned Miri toolchain when needed.
| File | Description |
|---|---|
Justfile |
Ensures the pinned nightly and Miri are installed. |
.github/workflows/ValidatePullRequest.yml |
Adds dedicated X64 and arm64 Miri jobs. |
.github/workflows/dep_miri.yml |
Defines the hosted-runner Miri workflow. |
.github/workflows/dep_build_test.yml |
Removes repeated Miri execution. |
.github/workflows/DailyArm64.yml |
Adds scheduled arm64 Miri coverage. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This comment has been minimized.
This comment has been minimized.
Miri interprets rather than executing. It reaches no hypervisor, reads no guest binary and asks nothing of a runner beyond the target it compiles for, yet it ran on every Linux build-and-test job: eight times over on X64 and twice on aarch64, for two answers, each on a pool the hypervisor jobs were queuing for. It runs once per architecture now, in a job of its own on the hosted runners. The build-and-test jobs shed a step that was a sizeable share of what was left between them and their timeout, and the hypervisor pools stop spending a slot on work that never asked for one. The shared setup is not used there. It reads /dev/kvm to report what the runner offers, which a hosted one need not have, and installs a C toolchain and spare Rust versions for builds Miri does not do. A toolchain, just and nextest are what it wants. `miri-tests` installs the pinned nightly it names rather than expecting the runner to carry it, which is what let it assume a provisioned image before. It still takes no arguments, which is what makes one job per architecture enough. Should it ever take a profile or a feature, that becomes another axis and the matrix has to grow with it. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Jorge Prendes <jorge.prendes@gmail.com>
The nightly musl matrix ran Miri in all eight of its entries, on the same pools the pull request matrix was freed from. Its `TARGET_TRIPLE` never reaches the recipe, which builds for the host with plain cargo, and the toolchain it pins is the same one every other job uses, so the eight runs covered what one does. The aarch64 daily run waited on the guest builds before starting. Miri reads no guest binary, so it now waits for nothing and reports even when they fail. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Jorge Prendes <jorge.prendes@gmail.com>
jprendes
force-pushed
the
split-build-test
branch
from
October 8, 2026 09:14
fb94150 to
58ffc74
Compare
jprendes
enabled auto-merge (squash)
October 8, 2026 09:17
andreiltd
approved these changes
Oct 8, 2026
Benchmark ResultsMeasured commit: kvm / amd (Linux) (➖ stable)No benchmark improved or regressed. Benchmark Resultsfunction_call_codec
payload_allocation
sandboxes
slot_pool
snapshot_files
virtq_readonly
virtq_readwrite
kvm / intel (Linux) (➖ stable)No benchmark improved or regressed. Benchmark Resultsfunction_call_codec
payload_allocation
sandboxes
slot_pool
snapshot_files
virtq_readonly
virtq_readwrite
mshv3 / amd (Linux) (➖ stable)No benchmark improved or regressed. Benchmark Resultsfunction_call_codec
payload_allocation
sandboxes
slot_pool
snapshot_files
virtq_readonly
virtq_readwrite
mshv3 / intel (Linux) (➖ stable)No benchmark improved or regressed. Benchmark Resultsfunction_call_codec
payload_allocation
sandboxes
slot_pool
snapshot_files
virtq_readonly
virtq_readwrite
hyperv-ws2025 / amd (Windows) (➖ stable)No benchmark improved or regressed. Benchmark Resultsfunction_call_codec
payload_allocation
sandboxes
slot_pool
snapshot_files
virtq_readonly
virtq_readwrite
hyperv-ws2025 / intel (Windows) (➖ stable)No benchmark improved or regressed. Benchmark Resultsfunction_call_codec
payload_allocation
sandboxes
slot_pool
snapshot_files
virtq_readonly
virtq_readwrite
Reported by |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
build-testhas been creeping towards its timeout, close enough that whether arun finishes is becoming a matter of luck. A sizeable share of what is left
between the job and that limit is spent on Miri.
Miri interprets rather than executing. It reaches no hypervisor, reads no guest
binary, and asks nothing of a runner beyond the target it compiles for. It ran
on every Linux
build-testjob regardless: eight times over on X64 and twice onaarch64, for two answers, each one occupying a pool the hypervisor jobs were
queuing for.
What this does
Miri runs once per architecture, in a job of its own, on the hosted runners.
build-testsheds the step, and the hypervisor pools stop spending slots onwork that never asked for one.
The architecture is the only axis its results depend on.
just miri-teststakesno arguments: its features are fixed in the recipe and no profile is passed, so
the hypervisor, the cpu vendor and the build configuration cannot change what it
covers. Should it ever take a profile or a feature, that becomes another axis
and the matrix has to grow with it, which is why the assumption is written down
beside the job.
Hosted runners
The shared setup is not used there. It reads
/dev/kvmto report what therunner offers, which a hosted one need not have, and installs a C toolchain and
spare Rust versions for builds Miri does not do. A toolchain,
justandcargo-nextestare what it wants.miri-testsinstalls the pinned nightly it names rather than expecting therunner to carry it. That is what let it assume a provisioned image before, and
it is also why the recipe now works on a fresh machine.
Verified
The Miri suite passes on a machine with no hypervisor infrastructure, which is
what the hosted runners are.
bindgenandccare the only build dependenciesthat would need more than a Rust toolchain, and both sit behind the macOS and
hvfgate in the host's build script, so neither is reached here.cargo-nextestwas installed forbuild-testsolely for Miri. Nothing elseuses it, so it goes with it.