Repository navigation
test: leave the duration attribute out of the build-to-build comparison - #43
Merged
Merged
Conversation
Owner
Author
|
local-ci: b74b5e1 | ruff n/a (no Python change) | cargo fmt, clippy -D warnings and cargo test ok (cap parity with the Python build: 15 passed, Windows) | readme n/a |
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.
Corrects the cause I gave in the issue text of #42 and fixes the flake in the test. Tier: low (tests only; nothing in
srcorrust/srcchanges).Fixes #42.
What the issue got wrong: it said the Rust build truncates the command time to whole milliseconds while the Python build rounds it. That is true only of Python's shell-hook ingestion (
commands/term.py, which reads$EPOCHREALTIME).cdg cap, which the test runs, measures incore/runner.pywithint((time.monotonic() - started) * 1000), and Rust withstarted.elapsed().as_millis(): both truncate, so the two builds agree on how a given elapsed time is stored.The flake is still real and has a different source: the test runs the command once with each build, and each run is timed separately. A command that takes about a millisecond (
sh -c 'echo ...; exit 1'on a fast runner) can come out as 0 ms in one run and 1 ms in the other, and an entry with 0 ms has nodurationattribute. Making Rust round would not remove this, only move the threshold to 0.5 ms.normaliseinrust/tests/capture_common/mod.rsnow drops theduration="..."attribute instead of masking its value, so the comparison no longer depends on whether a run was fast enough to have one.stable()in the same test file already removesduration_msfrom the stored JSON for the same reason.a_command_that_took_under_a_millisecond_compares_equal_to_one_that_took_longer: the same<command>with no duration,1msand1.5snormalise to one string.rust/src/term.rs(duration="1.5s").Tested locally on Windows:
cargo fmt --check,cargo clippy --all-targets -- -D warnings,cargo testpass;cargo test --test cap -- --include-ignoredwith the Python build fromuv sync --python 3.15andCODIGEST_PARITY=1: 15 passed. The failure itself needs a Linux runner and a sub-millisecond run, so it was not reproduced here; the new test checks the comparison directly instead. The ubuntu parity job is the real check.