chore: bump pydantic from 2.12.0 to 2.13.4#2604
Merged
Merged
Conversation
Bumps [pydantic](https://github.com/pydantic/pydantic) from 2.12.0 to 2.13.4. - [Release notes](https://github.com/pydantic/pydantic/releases) - [Changelog](https://github.com/pydantic/pydantic/blob/main/HISTORY.md) - [Commits](pydantic/pydantic@v2.12.0...v2.13.4) --- updated-dependencies: - dependency-name: pydantic dependency-version: 2.13.4 dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
tonyandrewmeyer
approved these changes
Jul 1, 2026
Collaborator
|
I wonder if we should run the integration tests for this one. |
Contributor
Good idea, run in progress now. |
Collaborator
I meant after #2586 - at the moment they're just skipped, so it won't tell us anything. |
james-garner-canonical
approved these changes
Jul 2, 2026
Integration tests call `Juju.show_model()`, which isn't available in the locked jubilant 1.5.0. The `jubilant~=1.5` constraint already allowed a newer version; refresh the lock to pick it up. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The integration workflow's matrix passes a file path (e.g.
test/integration/test_secrets.py) as posargs to tox. Because
tox.ini hardcoded test/integration/ before {posargs}, pytest
received both paths and collected the whole suite — so every
matrix leg ran every test, and test_tracing's function-scoped
tracing_juju fixture failed on the second tempo deploy into the
shared module-scoped juju model ("application "tempo" already
exists").
Move the default target into {posargs:...} so 'tox -e integration'
alone still runs the full suite, but posargs replace the target
when supplied.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The tracing integration tests were re-enabled with a matrix entry per test file, but the run that validated them used an entry per test function, so each test ran on its own runner with a fresh model. With both tests in one pytest invocation, the function-scoped tracing_juju fixture redeployed the tempo stack into the module-scoped model on the second test and failed with "application already exists". Have tracing_juju create its own temporary model instead of reusing the module-scoped one: both tests deploy the same charm under test and test_with_tls reconfigures tempo (enabling TLS), so a model cannot be shared between them. Extend the job timeout for the tracing file to cover the second stack deployment. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…ling The first run with per-test tracing models surfaced two timing races: test_with_tls got zero spans on Juju 3: after TLS is enabled, tempo's ingester ring takes minutes to re-form and the collector rejects spans with 503 "empty ring" until it does. The charm buffers rejected data and only retries on a later dispatch, but wait_spans gave up after 60 seconds. Raise that test's span timeout to 600 seconds and set a one minute update-status interval on the tracing model so retry dispatches arrive promptly. test_relation_units hit KeyError: 'peer' on machine Juju 4.1: relation membership propagates to each unit asynchronously, even after all units report active, so the action can observe a relation with no remote units yet (the endpoint is then absent from the results). Poll the action until the expected unit sets appear, with a five minute deadline. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The previous run showed test_with_tls receiving spans over TLS (the
ops.main assertion passed), but the start dispatch's trace was missing
while both earlier and later dispatches were present. That is expected:
the exporter persists a batch to the buffer only when the export thread
picks it up, and ops bounds the end-of-dispatch flush wait, so batches
queued while the collector rejects requests ("empty ring", while
tempo's ingester ring re-forms after enabling TLS) can be dropped.
Asserting StartEvent here demands a guarantee ops-tracing does not
make. Receiving ops.main spans over HTTPS is what the test is about;
test_direct_connection still checks StartEvent against a healthy
collector.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Collaborator
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
2 participants
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.
Bumps pydantic from 2.12.0 to 2.13.4.
Release notes
Sourced from pydantic's releases.
... (truncated)
Changelog
Sourced from pydantic's changelog.
... (truncated)
Commits
cf67d4bFix lintingf0d8a21Prepare release v2.13.45e3fe1dCheck for pydantic tag pattern in CI7f9edccDocument tagging conventionsb46a0c9Adaptpydantic-corelinker flags on macOS50629c8Update to PyPy 7.3.228522ebbPreserveRootModelcore metadataa37f3afAdaptMISSINGsentinel test to work with unreleasedtyping_extensionsver...909259aRemove Logfire example in documentation2c4174cBump libc from 0.2.155 to 0.2.185Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)