Skip to content

commonroad: regenerate the IDM demo fixtures with real checker verdicts - #129

Merged
kosuke55 merged 4 commits into
mainfrom
kosuke55/regenerate-idm-fixtures
Sep 21, 2026
Merged

kosuke55 merged 4 commits into
mainfrom
kosuke55/regenerate-idm-fixtures

Conversation

@kosuke55

Copy link
Copy Markdown
Owner

The straight_* demo fixtures predated the fix that starts the example's
solution at the planning problem's initial state, so both of them failed the
official starts_at_correct_state and the demo tables advertised that failure.
They are now the current example's output with the official checker's verdict
on it.

How. The checker (commonroad-drivability-checker) publishes
manylinux_x86_64 wheels only, so a real verdict cannot be produced on macOS or
ARM. This PR adds .github/workflows/commonroad-regenerate-fixtures.yml, a
workflow_dispatch-only job that runs the example in both modes on an ubuntu
runner, judges both solutions and uploads the six files. The committed fixtures
are that run's artifact:

https://github.com/kosuke55/drawtonomy/actions/runs/35613419629

commonroad-io 2024.3, commonroad-drivability-checker 2025.4.0, triangle
20250106 - the same versions the previous verdicts were produced with.

The new statuses.

mode verdict
idm PASS 7/7
naive FAIL 1/7 - obstacle_collision at t=37..44 (obstacle 2), the intended collision demo

Both solutions now start at time step 0 with 181 states, and each trace carries
the solutionFingerprint / scenarioFingerprint the writer computed during the
run.

Tests. test_committed_straight_fixtures_are_what_the_example_writes now
compares a fresh run state for state instead of "the fresh solution's tail from
step 1", and expects starts_at_correct_state to PASS for both modes, with
naive pinned to exactly one FAIL. The test proving the official rule rejects a
1-based solution used the committed fixture as its rejected shape; it now builds
that shape itself by dropping the first state of a fresh solution, so the rule
keeps being proved against something it must reject.

213 passed, 1 skipped locally (the skip is the checker-only verdict-shape test,
which the runner covers).

The straight_* demo fixtures are the example planner's output plus the
official checker's verdict on it. The checker ships manylinux_x86_64
wheels only, so a real verdict needs a Linux x86_64 runner. This job runs
the example in both modes, judges both solutions and uploads the six
files, so the fixtures can be regenerated without a local checker.
The six straight_* fixtures predate the fix that starts the example's
solution at the planning problem's initial state, so both of them failed
the official starts_at_correct_state. They are now the current example's
output, judged by the official checker on an ubuntu runner with
commonroad-io 2024.3, commonroad-drivability-checker 2025.4.0 and
triangle 20250106.

  idm    7/7 PASS
  naive  6/7, obstacle_collision FAIL at t=37..44 (obstacle 2), which is
         the point of the mode: it ignores the car ahead

Both solutions now start at time step 0 with 181 states, and both traces
carry the fingerprints of the committed solution and scenario.
The fixtures are now a plain rerun of the example, so the comparison is
state for state instead of "the fresh solution's tail from step 1", and
starts_at_correct_state is expected to PASS for both modes. naive is
pinned to exactly one FAIL, obstacle_collision.

The rule test that proved the official check rejects a 1-based solution
used the committed fixture as its rejected shape. It now builds that
shape itself, by dropping the first state of a fresh solution, so the
check keeps being proved against something it must reject.
The demo tables still described the old fixtures. Both READMEs now read
idm PASS 7/7 and naive FAIL 1/7 (obstacle collision at 3.7 s, intended),
and the example README replaces its four-check summary with the real
seven-check outcome on the straight road.

ATTRIBUTION records the workflow run that produced the files and the
checker versions it used, and drops the note saying the fixtures are
deliberately kept as the older 1-based output.
@kosuke55 kosuke55 added the run-tests Trigger CI test execution label Sep 21, 2026
@kosuke55
kosuke55 merged commit eccc7d5 into main Sep 21, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

run-tests Trigger CI test execution

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant