–reset-goldens deletes the golden dataset and nothing recreates it
Table of Contents
This page is a capture in the inbox bucket of the product backlog — a pre-sprint idea, not yet pulled into a sprint as a story.
1. What
Resolve the broken loop around --reset-goldens. Either teach the twelve
golden suites to write a golden that is missing when the flag is set, or
stop telling the reader to run it.
2. Why
The message reads as an instruction a developer can follow. It is not. The flag sits on the codegen script that regenerates the domain types, and it only removes the dataset:
# projects/ores.codegen/scripts/xsdcpp_generate.sh if [ -n "$RESET_GOLDENS" ]; then rm -rf "${GIT_ROOT}/${RESET_GOLDENS}" fi
Nothing then writes the goldens back. Every one of the twelve suites
fails on the next run with REQUIRE(exists(gpath)) instead of
bootstrapping, which the script's own help text promises: "Delete DIR
before regenerating, so golden tests re-bootstrap on next test run".
The gap matters most on an XSD bump, which is exactly when the message appears. The regeneration change makes the goldens stale, so the workflow wants to reset them; resetting them empties the directory; the suite then has no way to refill it.
xml_example_coverage_tests.cpp closes the loop for its own dataset
with ORES_BOOTSTRAP_GOLDENS=1, and that mechanism already fills gaps
only, so an existing golden is always compared. Whichever way this is
resolved, that test's behaviour is the shape to copy: a missing golden
is written, a present golden is compared, and the mode is explicit
rather than implied.
3. References
projects/ores.codegen/scripts/xsdcpp_generate.sh, the--reset-goldenshandler.projects/ores.codegen/scripts/xsdcpp_generate_ore.sh, the ORE wrapper that hard-codes the dataset path.projects/ores.ore/core/tests/xml_*_golden_roundtrip_tests.cpp, the twelve suites that print the message.
4. See also
- Update ORE to v17, the story that hit this.