Skip to content

chore: bump minio from 7.2.18 to 7.2.20#2606

Open
dependabot[bot] wants to merge 8 commits into
mainfrom
dependabot/uv/minio-7.2.20
Open

chore: bump minio from 7.2.18 to 7.2.20#2606
dependabot[bot] wants to merge 8 commits into
mainfrom
dependabot/uv/minio-7.2.20

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Jul 1, 2026

Copy link
Copy Markdown
Contributor

Bumps minio from 7.2.18 to 7.2.20.

Release notes

Sourced from minio's releases.

Bugfix Release 7.2.20

What's Changed

Full Changelog: minio/minio-py@7.2.18...7.2.20

Bugfix release 7.2.19

What's Changed

New Contributors

Full Changelog: minio/minio-py@7.2.18...7.2.19

Commits

Dependabot compatibility score

Dependabot 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 rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will 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 version will 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 dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Bumps [minio](https://github.com/minio/minio-py) from 7.2.18 to 7.2.20.
- [Release notes](https://github.com/minio/minio-py/releases)
- [Commits](minio/minio-py@7.2.18...7.2.20)

---
updated-dependencies:
- dependency-name: minio
  dependency-version: 7.2.20
  dependency-type: direct:development
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added the dependencies Issue/PR created by dependabot label Jul 1, 2026
@tonyandrewmeyer

Copy link
Copy Markdown
Collaborator

We should perhaps run the integration tests here.

tonyandrewmeyer and others added 6 commits July 2, 2026 19:55
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>
@tonyandrewmeyer

Copy link
Copy Markdown
Collaborator

Passing integration tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Issue/PR created by dependabot

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant