tests/consumer/functional/ is in no CI job's path. The jobs run:
consumer-smoke → tests/consumer/smokeapi-smoke → tests/api/smokeprovider-smoke → tests/provider/smoke
So the three registration tests added in #21 — including the privacy-consent enforcement check — never execute in CI. They pass locally against dev.
Worth a deliberate decision
There is a real argument for leaving it: those tests create real user accounts in the Keycloak realm. They clean up in fixture teardown and skip entirely when no admin token is available, so they are safe, but not running them on every push is a defensible default rather than an oversight.
The problem is that it currently is an oversight — the path simply was never added, and nothing records the choice.
Options:
- Leave as-is and document that
tests/consumer/functional/ is local/manual only.
- Add the path to
consumer-smoke, which already selects smoke or functional on workflow_call and workflow_dispatch, so the registration tests would run on deploys but not on every push.
- Run them on a schedule rather than per-merge.
Option 2 matches the existing marker logic most closely.
tests/consumer/functional/is in no CI job's path. The jobs run:consumer-smoke→tests/consumer/smokeapi-smoke→tests/api/smokeprovider-smoke→tests/provider/smokeSo the three registration tests added in #21 — including the privacy-consent enforcement check — never execute in CI. They pass locally against dev.
Worth a deliberate decision
There is a real argument for leaving it: those tests create real user accounts in the Keycloak realm. They clean up in fixture teardown and skip entirely when no admin token is available, so they are safe, but not running them on every push is a defensible default rather than an oversight.
The problem is that it currently is an oversight — the path simply was never added, and nothing records the choice.
Options:
tests/consumer/functional/is local/manual only.consumer-smoke, which already selectssmoke or functionalonworkflow_callandworkflow_dispatch, so the registration tests would run on deploys but not on every push.Option 2 matches the existing marker logic most closely.