Use specific exit status for pytest test failures be able to retry infra failures - #7611
Use specific exit status for pytest test failures be able to retry infra failures#7611nccatoni wants to merge 4 commits into
Conversation
|
|
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6f88082fad
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - 1-41 | ||
| - 43-255 |
There was a problem hiding this comment.
Replace unsupported exit-code ranges
For every nonempty generated child pipeline, YAML parses 1-41 and 43-255 as strings, but GitLab's retry:exit_codes documentation permits a single integer exit code or an array of integer exit codes, not range expressions. GitLab therefore rejects the generated configuration before its jobs can run; enumerate the desired codes or restructure the retry logic instead.
Useful? React with 👍 / 👎.
| if exitstatus == pytest.ExitCode.TESTS_FAILED: | ||
| session.exitstatus = TEST_FAIL_EXIT_CODE |
There was a problem hiding this comment.
Preserve retryability for fixture infrastructure errors
When infrastructure fails while a pytest fixture is starting or stopping, pytest also returns ExitCode.TESTS_FAILED; for example, the PARAMETRIC jobs create agent and library containers inside fixtures at tests/parametric/conftest.py:115-145, so a transient Docker error there produces a setup/teardown error with exit code 1. This hook converts that error to 42, which the new GitLab retry policy deliberately excludes, so precisely those infrastructure failures are not retried; only call-phase test failures should receive the special code.
Useful? React with 👍 / 👎.
cbeauchesne
left a comment
There was a problem hiding this comment.
See my comment on slack : If a scenario fails to start because of an failed healthcheck, will it be retried ? If yes, it's a red flag.
Basically, retry are authorized, if and only if :
- the fail reason is perfectly identified
- and it is absolutely outside of tested components scope
Motivation
Changes
Workflow
🚀 Once your PR is reviewed and the CI green, you can merge it!
🛟 #apm-shared-testing 🛟
Reviewer checklist
tests/ormanifests/is modified ? I have the approval from R&P teambuild-XXX-imagelabel is present