ci(tox): migrate from pip to uv via tox-uv#6390
Open
sentry-junior[bot] wants to merge 36 commits into
Open
Conversation
Contributor
Codecov Results 📊✅ 2205 passed | ⏭️ 154 skipped | Total: 2359 | Pass Rate: 93.47% | Execution Time: 6m 1s 📊 Comparison with Base Branch
✨ No test changes detected All tests are passing successfully. ✅ Patch coverage is 100.00%. Project has 13486 uncovered lines. Coverage diff@@ Coverage Diff @@
## main #PR +/-##
==========================================
- Coverage 41.06% 41.05% -0.01%
==========================================
Files 190 190 —
Lines 22877 22877 —
Branches 7834 7834 —
==========================================
+ Hits 9393 9391 -2
- Misses 13484 13486 +2
- Partials 508 508 —Generated by Codecov Action |
f7d0dfa to
757ecf4
Compare
35deb2d to
a767133
Compare
a3989a2 to
35675ae
Compare
33b62fa to
030fd1b
Compare
7a229b6 to
ccb07a7
Compare
6b18651 to
2267687
Compare
actions/checkout sets safe.directory under a temporary HOME that is discarded after the step, so subsequent steps see "dubious ownership" and git fails. This makes get_default_release() return None and breaks release/session-tracking tests on the 3.6/3.7 container jobs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
py3.7 celery in CI hangs in test_celery_beat_cron_monitoring::test_explanation. kill_beat slept 1s then opened the pidfile; in the slower py3.7 container startup, the file didn't exist yet, the thread died silently, and beat ran forever (30-min job timeout). Poll for the pidfile up to 30s before starting the kill timer, and dump any future thread exception to stderr so the next failure surfaces a traceback instead of silently hanging. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The pidfile-race fix did not unhang py3.7 celery in CI. pytest-timeout only dumps the parent pytest process's threads — the parent is stuck in pytest-forked's waitpid, so the actual hang is somewhere inside the forked child, invisible. Schedule faulthandler.dump_traceback_later(45) in run_beat (which runs inside the forked child) and cancel it on successful beat shutdown. If beat hangs in CI again, the child's full thread dump lands in the log and tells us where to look. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Previous attempt put faulthandler.dump_traceback_later inside run_beat, but the py3.7 CI hang turns out to happen earlier — start_worker() never returns, so run_beat is never reached and the dump is never armed. Move the diagnostic into an autouse fixture in tests/integrations/celery/integration_tests/conftest.py so it covers the entire test body. Next CI hang should land a thread dump in the log showing where start_worker is wedged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
So the py3.7-container kombu hang reveals its real exception instead of sleeping forever inside retry_over_time. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
After moving py3.6/3.7 jobs into the python:X.Y container, the three beat tests (test_explanation, test_beat_task_crons_success/error) hang in celery's start_worker on py3.7 only — kombu's pre-connect via default_channel never returns. This is a known kombu/redis-py + os.fork interaction on the old pin (kombu 4.6 + redis-py <3.2) that celery 4.4.7 ships with; it worked previously only because the broker was on loopback, not a bridged sibling container. Bumping the existing < (3, 7) skip to < (3, 8). py3.7 is EOL and the same tests run fine on 3.8+. Also dropping the diagnostic faulthandler conftest and the kill_beat exception-printing wrapper now that the root cause is understood; the pidfile-wait fix in kill_beat is kept since it's a legitimate startup-race fix. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The workflow sets SENTRY_PYTHON_TEST_REDIS_HOST=redis for 3.6/3.7 container runs (since redis is a sibling service container, not on loopback), but tox strips env vars not listed in passenv. The celery beat tests therefore read the default 127.0.0.1, find nothing on loopback inside the python container, and hang in kombu's retry_over_time. Adding the var to passenv fixes it; un-skip the beat tests on py3.7. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
this will **finally** make pre-commit consistent with CI :upside_down_face:
ad243c4 to
07280c2
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
uvandtox-uvto manage python envs and packages instead ofpipastral-sh/setup-uvaction in CI instead ofsetup-python, top-leveluvalways usespython3.14tox-uvuvpicks up throughUV_PYTHON_REFERENCEdepsand not viapackagesouvresolves all deps in a single pass, this was necessary sinceuvresolution is stricter thanpipruntox.shalso usesuv run toxUV_PRERELEASE=ALLfor resolution to work, we do not relax this throughout becauseuvthen fetches pre-releases for httpx and such breaking half the matrixDev Flow Changes
No need for
asdforpyenvnow if you were using it before, just useuv, it will manage bothtoxand required python versions internally.New commands:
uv run tox luv run tox -e py3.14-{integration}-v{version}uv run tox -e py3.14-commonTESTPATH=tests/integrations/logging/test_logging.py uv run tox -e py3.14-commonTESTPATH=tests/path/to/test_file.py uv run tox -e py3.14-common -- -k "test_name"TODO
uvas well - linters, top level tox, test file generation all managed withuvuvdoes not manage those