GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||||
GeezerVison is showing github.com — gh-62432: unittest runner: Exit code 5 if no tests were run by stefanor · Pull Request #102051 · python/cpython Conversation
|
|
Tests/macOS is routinely failing; ignore currently. This is a design bug fix, hence enhancement (feature change), as much as I would like to pretend otherwise. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Urgh, that removal wasn't intentional, I just hit the re-request review button. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
@gpshead: Ping? (it's been 2 months) |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Thank you! |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
- Either test filtering is used - Sharding is used and the shard index > 0, i.e. only the first shard will fail when no tests ran on Python 3.12+. Context: Python 3.12 unittest will now fail when no tests ran after the change from python/cpython#102051. Since `absltest` is built on top of `unittest`, it will follow this behavior change in Python 3.12. However, when test filtering is used in `absltest`, often used via `bazel test --test_filter=<my_filter>`, the current user expectation is the `bazel test` command should NOT fail is at least one test ran. Since the test runner here has no visibility of the overall `bazel` invocation, we'll make the test not fail when test filtering is used. This is the existing behavior before Python 3.12. Also test absl-py on Python 3.12. PiperOrigin-RevId: 565190992
- Either test filtering is used - Sharding is used and the shard index > 0, i.e. only the first shard will fail when no tests ran on Python 3.12+. Context: Python 3.12 unittest will now fail when no tests ran after the change from python/cpython#102051. Since `absltest` is built on top of `unittest`, it will follow this behavior change in Python 3.12. However, when test filtering is used in `absltest`, often used via `bazel test --test_filter=<my_filter>`, the current user expectation is the `bazel test` command should NOT fail is at least one test ran. Since the test runner here has no visibility of the overall `bazel` invocation, we'll make the test not fail when test filtering is used. This is the existing behavior before Python 3.12. Also test absl-py on Python 3.12. PiperOrigin-RevId: 565190992
- Either test filtering is used - Sharding is used and the shard index > 0, i.e. only the first shard will fail when no tests ran on Python 3.12+. Context: Python 3.12 unittest will now fail when no tests ran after the change from python/cpython#102051. Since `absltest` is built on top of `unittest`, it will follow this behavior change in Python 3.12. However, when test filtering is used in `absltest`, often used via `bazel test --test_filter=<my_filter>`, the current user expectation is the `bazel test` command should NOT fail is at least one test ran. Since the test runner here has no visibility of the overall `bazel` invocation, we'll make the test not fail when test filtering is used. This is the existing behavior before Python 3.12. Also test absl-py on Python 3.12. PiperOrigin-RevId: 565190992
- Either test filtering is used - Sharding is used and the shard index > 0, i.e. only the first shard will fail when no tests ran on Python 3.12+. Context: Python 3.12 unittest will now fail when no tests ran after the change from python/cpython#102051. Since `absltest` is built on top of `unittest`, it will follow this behavior change in Python 3.12. However, when test filtering is used in `absltest`, often used via `bazel test --test_filter=<my_filter>`, the current user expectation is the `bazel test` command should NOT fail is at least one test ran. Since the test runner here has no visibility of the overall `bazel` invocation, we'll make the test not fail when test filtering is used via bazel's environment variable. This is the existing behavior before Python 3.12. Also test absl-py on Python 3.12. PiperOrigin-RevId: 565190992
- Either test filtering is used - Sharding is used and the shard index > 0, i.e. only the first shard will fail when no tests ran on Python 3.12+. Context: Python 3.12 unittest will now fail when no tests ran after the change from python/cpython#102051. Since `absltest` is built on top of `unittest`, it will follow this behavior change in Python 3.12. However, when test filtering is used in `absltest`, often used via `bazel test --test_filter=<my_filter>`, the current user expectation is the `bazel test` command should NOT fail is at least one test ran. Since the test runner here has no visibility of the overall `bazel` invocation, we'll make the test not fail when test filtering is used via bazel's environment variable. This is the existing behavior before Python 3.12. Also test absl-py on Python 3.12. PiperOrigin-RevId: 565190992
- Either test filtering is used - Or sharding is used and the shard index > 0, i.e. only the first shard will fail when no tests ran on Python 3.12+. Context: Python 3.12 unittest will now fail when no tests ran after the change from python/cpython#102051. Since `absltest` is built on top of `unittest`, it will follow this behavior change in Python 3.12. However, when test filtering is used in `absltest`, often used via `bazel test --test_filter=<my_filter>`, the current user expectation is the `bazel test` command should NOT fail is at least one test ran. Since the test runner here has no visibility of the overall `bazel` invocation, we'll make the test not fail when test filtering is used via bazel's environment variable. This is the existing behavior before Python 3.12. Also test absl-py on Python 3.12. PiperOrigin-RevId: 565190992
- Either test filtering is used - Or sharding is used and the shard index > 0, i.e. only the first shard will fail when no tests ran on Python 3.12+. Context: Python 3.12 unittest will now fail when no tests ran after the change from python/cpython#102051. Since `absltest` is built on top of `unittest`, it will follow this behavior change in Python 3.12. However, when test filtering is used in `absltest`, often used via `bazel test --test_filter=<my_filter>`, the current user expectation is the `bazel test` command should NOT fail is at least one test ran. Since the test runner here has no visibility of the overall `bazel` invocation, we'll make the test not fail when test filtering is used via bazel's environment variable. This is the existing behavior before Python 3.12. Also test absl-py on Python 3.12. PiperOrigin-RevId: 565190992
- Either test filtering is used - Or sharding is used and the shard index > 0, i.e. only the first shard will fail when no tests ran on Python 3.12+. Context: Python 3.12 unittest will now fail when no tests ran after the change from python/cpython#102051. Since `absltest` is built on top of `unittest`, it will follow this behavior change in Python 3.12. However, when test filtering is used in `absltest`, often used via `bazel test --test_filter=<my_filter>`, the current user expectation is the `bazel test` command should NOT fail is at least one test ran. Since the test runner here has no visibility of the overall `bazel` invocation, we'll make the test not fail when test filtering is used via bazel's environment variable. This is the existing behavior before Python 3.12. Also test absl-py on Python 3.12. PiperOrigin-RevId: 565190992
- Either test filtering is used - Or sharding is used and the shard index > 0, i.e. only the first shard will fail when no tests ran on Python 3.12+. Context: Python 3.12 unittest will now fail when no tests ran after the change from python/cpython#102051. Since `absltest` is built on top of `unittest`, it will follow this behavior change in Python 3.12. However, when test filtering is used in `absltest`, often used via `bazel test --test_filter=<my_filter>`, the current user expectation is the `bazel test` command should NOT fail is at least one test ran. Since the test runner here has no visibility of the overall `bazel` invocation, we'll make the test not fail when test filtering is used via bazel's environment variable. This is the existing behavior before Python 3.12. Also test absl-py on Python 3.12. PiperOrigin-RevId: 565190992
- Either test filtering is used - Or sharding is used and the shard index > 0, i.e. only the first shard will fail when no tests ran on Python 3.12+. Context: Python 3.12 unittest will now fail when no tests ran after the change from python/cpython#102051. Since `absltest` is built on top of `unittest`, it will follow this behavior change in Python 3.12. However, when test filtering is used in `absltest`, often used via `bazel test --test_filter=<my_filter>`, the current user expectation is the `bazel test` command should NOT fail is at least one test ran. Since the test runner here has no visibility of the overall `bazel` invocation, we'll make the test not fail when test filtering is used via bazel's environment variable. This is the existing behavior before Python 3.12. Also test absl-py on Python 3.12. PiperOrigin-RevId: 565190992
- Either test filtering is used - Or sharding is used and the shard index > 0, i.e. only the first shard will fail when no tests ran on Python 3.12+. Context: Python 3.12 unittest will now fail when no tests ran after the change from python/cpython#102051. Since `absltest` is built on top of `unittest`, it will follow this behavior change in Python 3.12. However, when test filtering is used in `absltest`, often used via `bazel test --test_filter=<my_filter>`, the current user expectation is the `bazel test` command should NOT fail is at least one test ran. Since the test runner here has no visibility of the overall `bazel` invocation, we'll make the test not fail when test filtering is used via bazel's environment variable. This is the existing behavior before Python 3.12. Also test absl-py on Python 3.12. PiperOrigin-RevId: 565771935
|
The new Python 3.12 message surprises users when all tests are skipped: see issue #113661. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
The PR description says:
Which seems to suggest that it should not fail test if all tests are skipped, as skipped tests are still "found", just intentionally skipped from running. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
Yeah, I'd agree with that. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
to ensure that the CI `colcon test` run works, because with a change to python 3.12 the `unittest` standard library used by default with colcon now exits with an error code of 5 for an empty test suite. See: colcon/colcon-core#678 See: python/cpython#102051
to ensure that the CI `colcon test` run works, because with a change to python 3.12 the `unittest` standard library used by default with colcon now exits with an error code of 5 for an empty test suite. Additionally removed old ros 1 integration tests. See: colcon/colcon-core#678 See: python/cpython#102051
to ensure that the CI `colcon test` run works, because with a change to python 3.12 the `unittest` standard library used by default with colcon now exits with an error code of 5 for an empty test suite. See: colcon/colcon-core#678 See: python/cpython#102051
to ensure that the CI `colcon test` run works, because with a change to python 3.12 the `unittest` standard library used by default with colcon now exits with an error code of 5 for an empty test suite. Additionally removed old ros 1 integration tests. See: colcon/colcon-core#678 See: python/cpython#102051
Python 3.10 is in the test matrix, and on 3.10 unittest still exits 0 when it discovers no tests at all -- exit code 5 for "NO TESTS RAN" only landed in 3.12 (python/cpython#102051). So if tests/ were ever renamed or moved, the 3.10 leg would report success while running nothing at all. Capture the runner output and fail explicitly when zero tests were collected. Once tests are actually discovered the new branch cannot trigger. Verified both paths locally under `bash -eo pipefail`, the shell GitHub Actions uses: a simulated zero-test run (exit 0, "Ran 0 tests") is rejected with exit 1, and a normal 19-test run passes through untouched.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
running a suite with no tests is not an error
There was an error while loading. Please reload this page.