infrahub-managing-checks

Creates Infrahub check definitions with Python validation logic, GraphQL queries, and YAML-driven tests.

9|2|Updated Aug 27, 2025
One-click install
npx skills add https://github.com/opsmill/infrahub-solution-ai-dc --skill infrahub-managing-checks-opsmill
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: infrahub-managing-checks
Source: https://github.com/opsmill/infrahub-solution-ai-dc/tree/main/.agents/skills/infrahub-managing-checks
Command: npx skills add https://github.com/opsmill/infrahub-solution-ai-dc --skill infrahub-managing-checks-opsmill

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires infrahub-sdk, and includes references (resource) components.

What problem does it solve? Writing Infrahub checks requires coordinating three components — a GraphQL query, a Python InfrahubCheck class, and .infrahub.yml registration — and common mistakes like adding a forbidden query field or calling a nonexistent log_warning method cause silent passes or config validation failures. ## Core Features & Use Cases - Check Authoring Guidance: Walks through building global and targeted checks, from GraphQL query design to validate() implementation with correct log_error/log_info usage. - Registration Rules: Documents the exact .infrahub.yml check_definitions shape, including the extra="forbid" constraint that rejects a query field and the targets/parameters mapping for targeted checks. - YAML-Driven Testing: Covers the Resources Testing Framework with check-smoke, check-unit-process, and check-integration test kinds plus fixture directory structures. - Use Case: You need to block proposed changes when two devices occupy the same rack unit. The skill guides you to write a rack_devices.gql query, a RackUnitCollisionCheck class, register it in .infrahub.yml, and add pass/fail unit tests with JSON fixtures. ## Quick Start Create an Infrahub check that validates no two devices share the same rack unit position and register it in .infrahub.yml.

Frequently Asked Questions about infrahub-managing-checks

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create an Infrahub check for proposed changes?▼

Create three components: a GraphQL .gql query file, a Python class inheriting from InfrahubCheck that implements validate(), and a check_definitions entry in .infrahub.yml. The class query attribute must match the query name registered under the top-level queries section.

What is the difference between global and targeted Infrahub checks?▼

Global checks omit the targets field and run once per proposed change against all objects of a type. Targeted checks specify a CoreStandardGroup in targets and run once per group member, using parameters to map target attributes to GraphQL variables.

Why does my .infrahub.yml fail validation with extra fields not permitted?▼

The check_definitions config model uses extra="forbid", so adding a query field under a check entry raises a Pydantic validation error. The query belongs on the Python class as query = "name", unlike generator_definitions which does accept a top-level query field.

Does InfrahubCheck have a log_warning method?▼

No, InfrahubCheck only provides log_error and log_info. Calling log_warning raises AttributeError and fails the check with a traceback. For non-blocking warnings, use log_info with a "WARNING:" prefix in the message.

How do I test an Infrahub check locally before merging?▼

Run infrahubctl check <name> against a feature branch to exercise the same SDK path as the pipeline. You can also define YAML-driven tests using check-smoke, check-unit-process with input.json fixtures, and check-integration kinds.

When should I use a schema constraint instead of a Python check?▼

Use schema constraints for uniqueness, required fields, dropdown choices, regex patterns, and relationship cardinality, since they run on every write path. Reserve Python checks for cross-node business rules and stateful assertions that only run in the proposed change pipeline.