ci: drop the pydantic-ai v2 beta early-warning job (#359)

The v2-beta job was a non-blocking visibility signal, not a required
check. Removing it since it is no longer needed.
This commit is contained in:
Aditya Vardhan
2026-07-13 21:38:47 +05:30
committed by GitHub
parent 3ba9e2f9a5
commit 4ee2b3291f
-63
View File
@@ -148,69 +148,6 @@ jobs:
- run: uv sync --locked --group dev --all-extras
- run: uv run --no-sync pytest
# Early-warning signal for the pydantic-ai v2 beta line. The harness targets
# the v1 line today (the `>=1.105.0` floor and the lock both resolve to v1),
# but that `>=` constraint also admits the v2 prereleases once prerelease
# resolution is enabled. This job pins the latest v2 beta so we see v2
# breakage as it lands -- e.g. v2 dropped the `calls` argument from
# `ToolManager.get_parallel_execution_mode`, which CodeMode still calls with
# the v1 signature -- rather than discovering it the day v2 is released.
#
# Deliberately absent from the `check` gate below: v2 is unreleased and the
# harness does not yet claim to support it, so a red result here is expected
# and must not block merges. It is a visible signal, not a required check.
test-v2-beta:
runs-on: ubuntu-latest
name: test on pydantic-ai v2 beta
timeout-minutes: 20
# The whole point of the job is to resolve v2 prereleases; allow them for
# every uv invocation in this job rather than threading flags per step.
env:
UV_PRERELEASE: allow
steps:
- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
with:
persist-credentials: false
- uses: astral-sh/setup-uv@cec208311dfd045dd5311c1add060b2062131d57 # v8.0.0
with:
python-version: '3.14'
enable-cache: true # zizmor: ignore[cache-poisoning] -- Job does not produce release artifacts and does not have sensitive permissions
cache-suffix: v2-beta
# `env -u UV_LOCKED`: same as `test-latest` -- under the workflow-level
# `UV_LOCKED=1`, `uv lock` would assert the lockfile is current instead of
# applying the upgrade, so this step would fail the moment a newer v2 beta
# exists rather than testing it.
- run: |
env -u UV_LOCKED uv lock \
--prerelease allow \
--upgrade-package pydantic-ai-slim \
--upgrade-package pydantic-graph
- run: uv sync --locked --group dev --all-extras
# A v2 break can hang instead of failing cleanly: e.g. an unhandled
# exception raised inside a DBOS workflow leaves DBOS's background
# (non-daemon) recovery thread alive, so the Python process never exits
# and the step would otherwise ride to the 20-minute job timeout. The
# `timeout` wrapper caps the step so any such hang fails fast (exit 124)
# rather than burning a full runner slot. `-k 30` escalates to SIGKILL if
# pytest ignores the initial SIGTERM. A per-test plugin (pytest-timeout)
# would not catch this -- the hang happens after the test body finishes,
# during interpreter shutdown -- so the cap has to be on the process.
#
# Two instrumentation assertions depend on pydantic-ai v1's OpenTelemetry
# attribute and span names (`gen_ai.usage.*`, span `agent run`). v2 deliberately
# renamed these (aggregated-usage attributes, and GenAI-semconv span names
# such as `invoke_agent {name}`), so they are expected-red on v2 and carry
# no signal here. Deselect them so this job stays a meaningful early-warning
# for capability breakage (e.g. code mode) rather than documented
# instrumentation drift. If either test is renamed the deselect stops
# matching and the job goes red, which is the right prompt to revisit.
- run: |
timeout -k 30 300 uv run --no-sync pytest \
--deselect "tests/logfire_variables/test_managed_prompt.py::test_baggage_propagates_to_run_and_child_spans" \
--deselect "tests/logfire_variables/test_managed_prompt.py::test_provider_backed_resolution_tags_v1_instrumentation_spans"
coverage:
needs: [test]
runs-on: ubuntu-latest