chore(deps-dev): bump infrahub-testcontainers from 1.9.8 to 1.10.0

[dependabot]

Bumps infrahub-testcontainers from 1.9.8 to 1.10.0.

Release notes

Sourced from infrahub-testcontainers's releases.

Infrahub - v1.10.0

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

The headline addition is graph path traversal - a new way to ask the question Infrahub's graph was built to answer: how is this connected to that? A new GraphQL API and a visual topology explorer let you trace every path between two objects, or find everything reachable from a single node for impact analysis. Infrahub Enterprise also adds native LDAP authentication, completing external authentication for organizations without an OIDC/OAuth2 identity provider.

Alongside these, the release centers on three themes: authentication & identity - LDAP for Enterprise, auto-creation of account groups from identity-provider claims, and a reworked SSO account-identity model; performance & reliability - branch merges executed at the database level, precise artifact regeneration that only rebuilds what a commit actually changed, and a lighter computed-attribute and task pipeline; and API ergonomics - a structured, machine-readable GraphQL error catalogue and richer order_by controls for schema designers.

⚠️ This release includes several breaking changes. Read the Breaking changes section before upgrading - in particular the new structured GraphQL error codes, the reserved node_metadata name, restricted inheritance on internal Core generics, the BuiltinIPPrefix.resource_pool change and the restriction on using double underscores in schema attribute and relationship names.

⚠️ Single Sign-On accounts. v1.9.0 began capturing additional identity information against accounts created from OAuth2/OIDC providers, and warned that a future release would consume it. This is that release. v1.10.0 identifies SSO accounts by the provider-issued identity (sub) rather than the display name. A transitional setting, INFRAHUB_SECURITY_SSO_ACCOUNT_NAME_FALLBACK (enabled by default), still lets an SSO login reuse a pre-existing account by matching its display name, so upgrades remain smooth. Make sure every SSO user has logged in at least once, then disable the fallback as a hardening step - see Reworked SSO account identity below.

Main changes

Graph path traversal and topology explorer

Infrahub's data is stored in a graph, and 1.10 exposes the graph's most natural capability: traversal. Two new top-level GraphQL queries let you walk relationships across the entire model - not just physical cabling, but any relationship between objects.

• InfrahubPathTraversal finds the paths between two specific objects. Given a source_id and a destination_id, it returns the connecting paths (shortest first) as an ordered list of hops, each hop naming the node and the relationship traversed. Bound the search with max_depth and max_paths, and narrow it with kind_filter, relationship_filter, excluded_kinds, and excluded_namespaces.
• InfrahubReachableNodes answers "what depends on this?" Given a source_id and a list of target_kinds, it returns every reachable object of those kinds together with the shortest path to each - ideal for blast-radius and impact analysis ("if this device goes offline, what's affected?").

Traversal is branch- and time-aware, read-only, and permission-safe: any path that crosses an object the user cannot read is dropped entirely rather than leaked. A set of internal namespaces (Core, Internal, Builtin, Lineage, Profile, Template) is always excluded so results stay focused on your data; excluded_namespaces only adds to that set.

In the UI, a new Topology Explorer renders results as an interactive graph built on React Flow with automatic layout. You can switch between path mode and dependency mode, filter by kind and namespace, highlight an individual path, and step between paths from the keyboard. Object detail pages add a Trace from this object action to launch the explorer pre-seeded with that node. Because results are returned over GraphQL, the same traversal is available for AI assistants over the MCP server, allowing agents to get a full contextual understanding of data in the intended infrastructure graph.

LDAP authentication (Enterprise)

Infrahub Enterprise now supports native LDAP authentication against Active Directory, OpenLDAP, and other RFC 4510-compliant directories. This gives organizations that have no OIDC/OAuth2 identity provider a first-class external-authentication path that coexists with local accounts and SSO - all three can be active at once and converge on the same session, account, and group handling. On first successful login an Infrahub account is provisioned automatically, matching existing SSO behavior.

Configuration is via INFRAHUB_LDAP_* environment variables and is validated at startup. You can point Infrahub at one or more servers (the first is primary, the rest act as failover), choose bind-then-search with a service account, select the username_attribute appropriate to your directory (for example sAMAccountName on AD or uid on OpenLDAP), and secure the connection with LDAPS or STARTTLS. Optional group mapping (group_enabled) matches LDAP group membership - including nested groups - against existing Infrahub CoreAccountGroup names, granting permissions through the usual account-group → role → permission chain. Combined with auto-created groups (below), group membership can be provisioned on first login with no manual setup.

This feature is available on Infrahub Enterprise only.

Auto-create account groups from your identity provider

Infrahub can now create account groups automatically from identity-provider claims on login, so you no longer have to pre-create a CoreAccountGroup for every group your IdP (or LDAP directory) reports. The feature is opt-in and off by default.

Activate it by setting a claim filter:

• security.auto_create_groups_filter (INFRAHUB_SECURITY_AUTO_CREATE_GROUPS_FILTER) - a regular expression, or an ordered list of them, matched against each incoming group claim. The first match wins. A named capture group (?P<name>...) becomes the local group name (e.g. ^LDAP/group/(?P<name>.+)$ maps LDAP/group/network-eng to network-eng); with no capture the full claim is used. Non-matching claims are dropped, so unrelated IdP groups never appear in Infrahub. Setting this filter is what activates the feature; leaving it empty keeps auto-creation off.
• security.auto_create_groups_max_per_login - caps the number of new groups created in a single login (default 50). Reuse of existing groups is never capped. If the cap is hit, surplus claims are dropped, a warning event is emitted, and the login still completes.

Auto-created groups start with no roles or permissions and run on every external login (OIDC, OAuth2, and native LDAP). If at least one claim matches, it takes precedence over the existing security.sso_user_default_group fallback; if none match, that fallback still applies.

The groundwork of this feature was contributed by @​AlexanderGrooff in #8515

Reworked SSO account identity

Single Sign-On accounts are now keyed on the stable, provider-issued subject identifier (sub) together with the provider and protocol, stored on a dedicated CoreExternalIdentity node, rather than on the user's display name. This removes a class of problems where two users sharing a display name could collide, or where a changed display name produced a duplicate account on the next login. The human-readable name is now stored on the account's label attribute and is refreshed when it becomes stale.

... (truncated)

Changelog

Sourced from infrahub-testcontainers's changelog.

Infrahub - v1.10.0 - 2026-06-24

Security

• Bumped transitive docs dependencies to address Dependabot advisories: dompurify >= 3.4.0, follow-redirects >= 1.16.0, lodash and lodash-es >= 4.18.0, postcss >= 8.5.10, and uuid (v11) >= 11.1.1.

Added

• Object Templates now expose member_of_groups_for_instances and subscriber_of_groups_for_instances relationships. Groups assigned through these fields are propagated to every object created from the template, mirroring the resource-pool pattern. The existing member_of_groups and subscriber_of_groups on a template continue to apply to the template itself only. (#9094)

• Per-provider groups_claim setting for OAuth2 and OIDC providers: configure the JSON key used to extract the user's groups from the IdP claim payload (default groups). See the SSO guide for details. (#9144)

• Added graph path traversal feature with visual topology explorer. Users can discover paths between any two nodes, find dependencies from a source node, filter by kind and namespace, and explore the graph interactively with React Flow visualization.

• Infrahub can now auto-create account groups from identity-provider claims on SSO login. Opt in by configuring a claim filter under security.auto_create_groups_filter, with an optional per-login cap.

• The GraphQL order argument now uses a single, structured interface for ordering results:

  • order: {by: [{field: "name__value", direction: ASC}, {field: "node_metadata__created_at", direction: DESC}]}
  • field is an attribute (name__value), a relationship attribute (owner__name__value), or node metadata (node_metadata__created_at / node_metadata__updated_at). It no longer carries a trailing __asc/__desc suffix.
  • direction is an enum (ASC / DESC) and defaults to ASC when omitted.
  • When provided, by fully replaces the schema's order_by default. It works at the root level, on many-relationship fields, and on hierarchical (ancestors / descendants) relationships.

  The node_metadata field on the order argument is deprecated; order by metadata through by using the node_metadata__created_at / node_metadata__updated_at fields instead. node_metadata cannot be combined with by in the same input.

  Schema-level order_by entries are unchanged and still reference object-level metadata (node_metadata__created_at) with an optional __asc/__desc suffix. A UUID tiebreaker is always appended so ordering is stable across paths.

  Breaking change: node_metadata is a reserved attribute and relationship name. Schemas that literally use node_metadata as an attribute or relationship name will fail to load and must rename the offending element.

Changed

• Breaking: GraphQL error responses now carry a stable string code in extensions.code (e.g. "NODE_NOT_FOUND", "AUTHENTICATION_REQUIRED") and a typed extensions.data payload, plus a new integer extensions.http_status. Previously extensions.code was an integer mirroring the HTTP status. Consumers reading the integer code (most commonly on the /graphql auth-short-circuit path) must migrate to switching on the string code; numeric checks now read extensions.http_status. REST /api/... responses are unchanged.

• HFID attribute values are now indexed in Neo4j for faster lookups. A migration normalizes existing HFID values to consistent all-string format and adds database indexes. The HFID lookup query has been simplified to match directly on the stored value instead of reconstructing per-field filters.

• Improve merge performance by moving the logic to the database level

• Improved design of the account token list page

• Prefect task read queries optimized to fetch only required fields. client.all() and client.filters() calls replaced with targeted execute_graphql() queries in display_labels, hfid, computed_attribute, git, and generators tasks, significantly reducing data transfer per workflow execution.

• Refined graph path traversal API: renamed InfrahubDependencies to InfrahubReachableNodes, renamed node_filter input to kind_filter, added generic-kind support in filters, and hardened default-branch edge filtering.

• Rewrote the CLI reference and upgrade documentation for the 1.10 upgrade/migrate UX. The --verbose flag on infrahub db migrate and infrahub upgrade now correctly describes that it controls internal infrahub/prefect logger output (not per-migration progress, which is always shown). Developer-facing Raises: blocks are no longer leaked into the rendered CLI reference. The upgrade overview now explains the six-step upgrade pipeline, what operators should expect to see during an upgrade, and how to use db showmigrations, db showmigration N, and db migrate --plan. Every migration now carries a required description field that db showmigration N surfaces, so operators can see what each migration does without reading the source. Migrations 068–073 ship with real descriptions; older migrations are stubbed as N/A for now. The migration console no longer renders Rich file.py:NNN debug tags on every line.

• Several built-in Core generic schemas that have special handling in Infrahub now restrict inheritance to the Core namespace via the restricted_namespaces field. This prevents user-defined schemas from inheriting from generics whose code paths assume a specific internal structure.

  Breaking change. Any user-defined node schema that inherits from one of the generics listed below must be removed (and its data deleted) before upgrading. Infrahub will refuse to load a schema that violates these restrictions and the upgrade will not complete.

  The newly restricted generics are:

  • CoreCredential
  • CoreGenericAccount
  • CoreResourcePool
  • CoreIPPool
  • CoreTransformation
  • CoreBasePermission
  • CoreMenu
  • CoreComment
  • CoreThread
  • CoreValidator

... (truncated)

Commits

• 0be8357 chore: update docker-compose
• 03f7b5a prep release 1.10.0 (#9685)
• d9caee2 chore: update docker-compose
• c6ef331 Version 1.9.9 (#9674)
• 07705c0 fix(frontend): run repository commit imports against the current branch (#9668)
• cbc8b63 Merge pull request #9595 from opsmill/chore/agentic-structure
• a15d076 docs(dev): update agent-asset location to .agents/ in ADR and org guideline
• 89f3f8d docs(dev): point dev/README links to .agents/commands
• c5acd83 docs(agentic): tighten AGENTS.md; drop archival + Copilot-era instruction files
• 609ad42 chore(agentic): migrate source of truth to .agents/, fix adapter
• 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

Bump dev dependency infrahub-testcontainers to 1.10.0 to run tests against Infrahub v1.10 and keep the local test stack current. No app code changes.

• Dependencies
  • infrahub-testcontainers: 1.9.8 → 1.10.0
  • Transitive: prefect-client 3.6.13 → 3.7.4; new amplitude-analytics; adds starlette

^{Written for commit 1e575a7. Summary will update on new commits.}

[cloudflare-workers-and-pages]

Deploying infrahub-sdk-python with    Cloudflare Pages

Latest commit:	1e575a7
Status:	✅  Deploy successful!
Preview URL:	https://602591b7.infrahub-sdk-python.pages.dev
Branch Preview URL:	https://dependabot-uv-stable-infrahu-s553.infrahub-sdk-python.pages.dev

View logs