Skip to content

[fork-internal CI test] auto-derive installs dbf (not baked in)#9

Closed
eduralph wants to merge 3 commits intomaintenance/gramps60from
feature/ci-cd-pipeline-upstream
Closed

[fork-internal CI test] auto-derive installs dbf (not baked in)#9
eduralph wants to merge 3 commits intomaintenance/gramps60from
feature/ci-cd-pipeline-upstream

Conversation

@eduralph
Copy link
Copy Markdown
Owner

Second fork-internal CI test — verify auto-derive installs dbf at runtime now that it's no longer baked into the Dockerfile or environment.yml.

Do not merge. Upstream-facing PR is gramps-project#820 on gramps-project/addons-source.

The Dockerfile bakes in only `dbf`, but addons declare a wider set of
Python deps in their .gpr.py `requires_mod` lists (networkx, psycopg2,
pygraphviz, lxml, svgwrite, boto3, litellm, life_line_chart, psycopg).
Without these installed, per-addon unit tests and the plugin-
registration subprocess load fail with ImportError/NameError.

Add a pre-test step to unit-test-linux, unit-test-windows, and
integration-test that globs every *.gpr.py, extracts the requires_mod
union via ast.literal_eval, and pip-installs each package one at a
time. Per-package install (not batched) keeps a single build failure
(pygraphviz without graphviz-dev, psycopg2 without libpq-dev) from
aborting the rest — the affected addon's tests will skip or fail in
isolation without blocking others.

Mirrors Gramps' Addon Manager install path
(gramps/gui/plug/_windows.py __on_install_clicked → req.install →
gen/utils/requirements.py), keeping .gpr.py files as the single source
of truth for addon deps. New addon deps do not need a parallel update
to the Dockerfile or this workflow.
With ci.yml's auto-derive step in place (previous commit), dbf is
installed at CI runtime from TMGimporter's .gpr.py requires_mod list.
Keeping it baked into the Dockerfile and environment.yml in parallel
would defeat the "single source of truth = .gpr.py" goal and drift
the moment a new addon declares an additional dep.

Remove dbf from both; leave the stable base (PyGObject, pycairo,
Gramps, orjson, ruff) since those are not addon deps. Add a comment
pointing readers at the auto-derive step so future edits do not
re-bake runtime deps back in.
Root cause of "Unit Tests (Linux)" and "Integration Tests (Gramps)"
failures was not broken test modules — the steps never invoked
unittest. The container's default shell is /bin/sh (dash on
python:3.12-slim), and the inline scripts use bash-only parameter
expansions (${f%.py}, ${mod//\//.}) to build the dotted module list.
Dash fails with "Bad substitution" on the first such line; the rest
of the script never runs. continue-on-error: true masked this as a
generic job failure for two CI rounds.

Add "shell: bash" explicitly to:
- unit-test-linux / Run per-addon unit tests (bashisms)
- integration-test / Run per-addon integration tests (bashisms)
- integration-test / Run plugin registration tests (no bashisms today,
  but consistent and future-proof)

Compile Check already sets shell: bash. Windows jobs inherit bash
via defaults.run at the job level. No other steps affected.
@eduralph
Copy link
Copy Markdown
Owner Author

Auto-derive, dbf removal, and shell:bash fix all verified. Integration Tests: ✓. Unit Tests (Linux): 157/158 (1 pre-existing WebSearch import bug). PR gramps-project#820 CI infra now good; remaining red jobs are content bugs in specific addons, separate fixes.

@eduralph eduralph closed this Apr 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant