–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-goldens handler.
  • 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

Emacs 29.3 (Org mode 9.6.15)