Summary
The Sqlite addon's tests/test_sqlite.py::ExportSQLTestCase::test_export_sql fails against gramps core 6.1 while passing against 6.0, in the addon × core version matrix. Surfaced during a gramps-testbed-v2 root-cause recheck of issue 8653 (the addon-unit gate previously reported only a vague "runner exited 1, no parsed failures, no matching baseline signature"; the recheck resolves that into this concrete, named failure).
Observed (addon-unit matrix)
| Leg |
Result |
addons-source gramps60 × core 6.0 |
green (no failures) |
addons-source gramps61 × core 6.1 |
fail — 1 new failure not in baseline: Sqlite.tests.test_sqlite.ExportSQLTestCase::test_export_sql |
What the test does
A full round-trip through the addon (Sqlite/tests/test_sqlite.py:27-50): setUp imports example/gramps/example.gramps into a sqlite-backed DB, exportSQL(...) to /tmp/exported1.sql, opens a second sqlite DB; test_export_sql then importSQL(...) that file back. So the failure is in the export→import path against a 6.1 core, not a trivial assertion.
Not yet captured
The gate reports the baseline delta, not the underlying traceback/assertion — so the cause (exception type, which step fails) is not yet pinned. This needs triage: it could be
- a genuine Sqlite export/import regression,
- a core-6.1 API/schema interaction (it's 6.1-only), or
- baseline drift (the recorded baseline no longer matches).
Repro
From a gramps-testbed-v2 checkout with the per-version worktrees built:
CORE_VERSION=6.1 ./engine/scripts/ubuntu/run-addon-unit.sh Sqlite
(CORE_VERSION=6.0 for the passing leg, to confirm the 6.0/6.1 split.)
Filed on the fork because upstream gramps-project/addons-source has issues disabled (per the testbed's non-Mantis → fork-issue convention). Origin: gramps-testbed-v2 issue_8653 recheck.
Summary
The Sqlite addon's
tests/test_sqlite.py::ExportSQLTestCase::test_export_sqlfails against gramps core 6.1 while passing against 6.0, in the addon × core version matrix. Surfaced during a gramps-testbed-v2 root-cause recheck of issue 8653 (the addon-unit gate previously reported only a vague "runner exited 1, no parsed failures, no matching baseline signature"; the recheck resolves that into this concrete, named failure).Observed (addon-unit matrix)
addons-source gramps60 × core 6.0addons-source gramps61 × core 6.11 new failure not in baseline: Sqlite.tests.test_sqlite.ExportSQLTestCase::test_export_sqlWhat the test does
A full round-trip through the addon (
Sqlite/tests/test_sqlite.py:27-50):setUpimportsexample/gramps/example.grampsinto a sqlite-backed DB,exportSQL(...)to/tmp/exported1.sql, opens a second sqlite DB;test_export_sqlthenimportSQL(...)that file back. So the failure is in the export→import path against a 6.1 core, not a trivial assertion.Not yet captured
The gate reports the baseline delta, not the underlying traceback/assertion — so the cause (exception type, which step fails) is not yet pinned. This needs triage: it could be
Repro
From a gramps-testbed-v2 checkout with the per-version worktrees built:
(
CORE_VERSION=6.0for the passing leg, to confirm the 6.0/6.1 split.)Filed on the fork because upstream
gramps-project/addons-sourcehas issues disabled (per the testbed's non-Mantis → fork-issue convention). Origin: gramps-testbed-v2 issue_8653 recheck.