chore(deps-dev): bump infrahub-testcontainers from 1.10.8 to 1.11.0

[dependabot]

Bumps infrahub-testcontainers from 1.10.8 to 1.11.0.

Release notes

Sourced from infrahub-testcontainers's releases.

Infrahub - v1.11.0

We're excited to announce the release of Infrahub, v1.11.0!

Release highlights

The headline of 1.11 is scale and performance. Until now, almost any change caused Infrahub to redo work the change could not have affected: merging a branch re-ran every Generator and regenerated every artifact, and a single commit to a linked repository recomputed every Transformation-based computed attribute in the instance. On a large dataset that meant thousands of background tasks and an instance that stayed busy long after an action finished. 1.11 makes that work proportional to what actually changed.

Alongside this, webhook deliveries become first-class tasks you can inspect, retry and cancel. A delivery used to be an anonymous step inside a larger task, so you could not see what was sent, read what came back, or resend anything without re-firing the original event.

The release centers on three themes: performance at scale — selective regeneration after a merge, precise Generator and computed-attribute triggers, and narrower schema validation; operational visibility and recovery — webhook delivery operability, and detection of and recovery from a failed merge; and day-to-day usability — server-side sorting and filtering, and personal date and time preferences.

Before upgrading

Breaking changes

⚠️ Breaking changes in this release

• Artifact workflows after target removal: If your workflow relies on an artifact remaining available after its target is removed from the artifact definition's target group, Infrahub deletes that artifact on the next full generation pass. Capture any required content, or update the workflow, before removing the target.
• infrahub git-agent: Scripts or automation that still call this command will no longer work after upgrading. Replace those calls with the task worker.
• Generated OpenAPI clients: Code that depends on the previous component schema names in openapi.json needs to be updated and regenerated.
• API backpressure: Under sustained overload Infrahub now rejects requests with 429 Too Many Requests and a Retry-After header. The web UI and the Python SDK handle this for you; a custom integration that calls the API directly is expected to handle it itself.

The full Breaking changes section below explains the impact of each and the action to take.

Upgrade preparation

📌 Non-breaking preparation

• Separately managed Neo4j deployments: Upgrade Neo4j to 2026.05.0 alongside Infrahub.
• Python Transformations and Generator definitions with external dependencies: Add watch entries for modules imported from outside the Transformation's package directory.

The Infrahub container image includes Python 3.14 and Neo4j 2026.05.0. Expect a one-time recomputation the first time each Transformation is imported after upgrading.

Scale and performance

Work proportional to the change

Regenerate only what a merge actually changed

When you merge a branch or a Proposed Change, Infrahub now regenerates only the artifact and Generator definitions whose inputs the merge actually changed, and only for the members affected — instead of regenerating every definition for every member.

A merge captures its own diff and uses it to decide what to run. A definition is regenerated when its GraphQL query, its definition object, or its code changed, and its members are narrowed to the objects the change touched. Across the scenarios used to validate this, the number of regeneration tasks a merge produces fell by between 73% and 100%. When a merge runs a Generator, Infrahub waits for it to finish and then regenerates the artifacts built from the objects that Generator created or changed.

The rule the selection follows is that regenerating too much is acceptable and regenerating too little is not.

• Fallback behavior. A missing or unreadable diff, a definition with no fingerprint yet, and an incomplete dependency list each cause Infrahub to regenerate every member of that definition. This creates more tasks than necessary, but no affected artifact is left stale.
• Data referenced through relationships. An interface's description or an owner's name cannot always be resolved to specific members, so Infrahub regenerates all members of the affected definitions. Definitions that render relationship data therefore see a smaller reduction than those built directly from the changed objects.

Selective regeneration is controlled by selective_execution_after_merge (INFRAHUB_SELECTIVE_EXECUTION_AFTER_MERGE) and is enabled by default. Setting it to false restores full regeneration after every merge.

... (truncated)

Changelog

Sourced from infrahub-testcontainers's changelog.

Infrahub - v1.11.0 - 2026-08-17

We're excited to announce the release of Infrahub, v1.11.0!

Release highlights

The headline of 1.11 is scale and performance. Until now, almost any change caused Infrahub to redo work the change could not have affected: merging a branch re-ran every Generator and regenerated every artifact, and a single commit to a linked repository recomputed every Transformation-based computed attribute in the instance. On a large dataset that meant thousands of background tasks and an instance that stayed busy long after the merge finished. 1.11 makes that work proportional to what actually changed.

Alongside this, webhook deliveries become first-class tasks you can inspect, retry and cancel. A delivery used to be an anonymous step inside a larger task, so you could not see what was sent, read what came back, or resend anything without re-firing the original event.

The release centers on three themes: performance at scale — selective regeneration after a merge, precise Generator and computed-attribute triggers, and narrower schema validation; operational visibility and recovery — webhook delivery operability, and detection of and recovery from a failed merge; and day-to-day usability — server-side sorting and filtering, and personal date and time preferences.

Before upgrading

Breaking changes

⚠️ Breaking changes in this release

• Artifact workflows after target removal: If your workflow relies on an artifact remaining available after its target is removed from the artifact definition's target group, Infrahub deletes that artifact on the next full generation pass. Capture any required content, or update the workflow, before removing the target.
• infrahub git-agent: Scripts or automation that still call this command will no longer work after upgrading. Replace those calls with the task worker.
• Generated OpenAPI clients: Code that depends on the previous component schema names in openapi.json needs to be updated and regenerated.

The full Breaking changes section below explains the impact of each and the action to take.

Upgrade preparation

📌 Non-breaking preparation

• Separately managed Neo4j deployments: Upgrade Neo4j to 2026.05.0 alongside Infrahub.
• Python Transformations and generator definitions with external dependencies: Add watch entries for modules imported from outside the Transformation's package directory.

The Infrahub container image includes Python 3.14 and Neo4j 2026.05.0. Expect a one-time recomputation the first time each Transformation is imported after upgrading.

Scale and performance

Work proportional to the change

Regenerate only what a merge actually changed

When you merge a branch or a Proposed Change, Infrahub now regenerates only the artifact and Generator definitions whose inputs the merge actually changed, and only for the members affected — instead of regenerating every definition for every member.

A merge captures its own diff and uses it to decide what to run. A definition is regenerated when its GraphQL query, its definition object, or its code changed, and its members are narrowed to the objects the change touched. Across the scenarios used to validate this, the number of regeneration tasks a merge produces fell by between 73% and 100%. When a merge runs a Generator, Infrahub waits for it to finish and then regenerates the artifacts built from the objects that Generator created or changed.

The rule the selection follows is that regenerating too much is acceptable and regenerating too little is not.

• Fallback behavior. A missing or unreadable diff, a definition with no fingerprint yet, and an incomplete dependency list each cause Infrahub to regenerate every member of that definition. This creates more tasks than necessary, but no affected artifact is left stale.
• Data referenced through relationships. An interface's description or an owner's name cannot always be resolved to specific members, so Infrahub regenerates all members of the affected definitions. Definitions that render relationship data therefore see a smaller reduction than those built directly from the changed objects.

Selective regeneration is controlled by selective_execution_after_merge (INFRAHUB_SELECTIVE_EXECUTION_AFTER_MERGE) and is enabled by default. Setting it to false restores full regeneration after every merge.

... (truncated)

Commits

• 79760e0 fix version in docker compose file
• c6f1fa1 Merge pull request #10335 from opsmill/prep-release-1.11.0
• 992fde3 Merge remote-tracking branch 'origin/stable' into prep-release-1.11.0
• 1e79bc2 checkout python_sdk @​v1.23.0
• 3972f9a Merge pull request #10290 from opsmill/wvd-release-notes-1.11
• c0e7613 refactor: consolidate graph-integrity checks behind verify_graph() (#10250)
• b0d1fe3 add v1.11.0 release notes
• 85201d8 chore: update docker-compose
• bb13582 Merge pull request #10327 from opsmill/prep-release-1.10.9
• 122fa24 version bump to v1.10.9
• Additional commits viewable in compare view

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)

---

Summary by cubic

Bumps dev dependency infrahub-testcontainers from 1.10.8 to 1.11.0 so tests run against Infrahub v1.11.0. This introduces new defaults (selective regeneration after merges and API backpressure) that can change test behavior.

Review and rollout

• Only uv.lock changed; no app code changed.
• Tests calling the API must handle 429 Too Many Requests with Retry-After. Use a client with retries or add backoff.
• Tests that assumed full regeneration after merges should update expectations or set INFRAHUB_SELECTIVE_EXECUTION_AFTER_MERGE=false in the test environment.
• If CI manages Neo4j separately, bump it to 2026.05.0 to match the container image.

^{Written for commit 14fb8c0. Summary will update on new commits.}

[cloudflare-workers-and-pages]

Deploying infrahub-sdk-python with    Cloudflare Pages

Latest commit:	14fb8c0
Status:	✅  Deploy successful!
Preview URL:	https://1515bace.infrahub-sdk-python.pages.dev
Branch Preview URL:	https://dependabot-uv-stable-infrahu-7jxi.infrahub-sdk-python.pages.dev

View logs