Skip to content

CD pipeline fails in tests/test_release.py::test_run_functional_suite #17

Description

@luisfponce

Link

Summary

The CD workflow fails in the Python Tests job when pytest executes tests/test_release.py.
The failure is currently reported as a generic subprocess return-code assertion in test_run_functional_suite, which masks the specific functional test case that failed.

Current behavior

tests/test_release.py::test_run_functional_suite runs a nested pytest process against tests/functional and only checks returncode == 0. When one or more functional tests fail, the top-level test fails with a generic assertion:

E       AssertionError: assert 1 == 0
E        +  where 1 = CompletedProcess(..., returncode=1).returncode

This makes triage slower because the root failing test is not surfaced clearly from this wrapper test.

Expected behavior

When functional tests fail in CD:

  1. The failing functional test name and error details should be clearly visible in logs.
  2. The release gate should still fail, but with actionable diagnostics.

Evidence

From run logs:

tests/test_release.py::test_run_functional_suite FAILED
...
>       assert result.returncode == 0
E       AssertionError: assert 1 == 0
...
tests/test_release.py:13: AssertionError
...
collecting ... collected 47 items

Relevant files:

  • webapi/tests/test_release.py
  • .github/workflows/cd.yml

Likely root cause

At least one test inside webapi/tests/functional fails in CI/CD environment.
The wrapper test in webapi/tests/test_release.py obscures first-failure details by asserting only on process exit code.

Reproduction

  1. Run release wrapper locally from repository root:
    • cd webapi && pytest tests/test_release.py -v
  2. Run functional suite directly to expose failing case:
    • cd webapi && pytest tests/functional -v -x

Proposed fixes

Short term

  • Improve test_run_functional_suite diagnostics by printing captured stdout and stderr when return code is non-zero.
  • Optionally run with -x and --maxfail=1 to surface first failure quickly.

Medium term

  • Consider running tests/functional directly in workflow instead of invoking nested pytest from a pytest test file.
  • Keep test_release.py only if there is strong justification for wrapper behavior.

Acceptance criteria

  • CD failure logs show the specific failing test file and assertion in functional suite.
  • A contributor can identify root cause from one workflow run without rerunning locally.
  • tests/test_release.py no longer fails with only a generic subprocess assertion message.

Implementation checklist

  • Capture and display subprocess stdout and stderr in webapi/tests/test_release.py when failing.
  • Validate diagnostics quality by forcing one functional test failure on a test branch.
  • Confirm CD logs now expose actionable failure context.
  • Merge and verify next CD run readability.

Notes

Potentially related files to inspect after root-failure is known:

  • webapi/tests/functional/test_auth_routes.py
  • webapi/tests/functional/test_prompts_routes.py
  • webapi/tests/functional/test_users_routes.py
  • webapi/tests/functional/test_cd.py

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions