Describe the Feature Request
A proposed change today exposes its check-pipeline status only in decomposed
form: CoreProposedChange.validations → CoreValidator, where each validator
carries its own state (queued / in_progress / completed) and conclusion
(unknown / failure / success). There is no single, first-class field that
answers "has the whole check pipeline finished, and did it pass?" for a
proposed change.
Anyone who needs the overall answer has to fetch every validation and
aggregate the state/conclusion fields themselves, and poll that list until
all validators reach completed before the conclusions are meaningful.
Describe the Use Case
The staged-review workflow encourages automating the Infrahub-side review from
CI: a pipeline creates the branch, triggers the import, opens the proposed
change, and blocks the Git pull request from merging until the Infrahub checks
pass. To gate the PR, that pipeline needs one reliable signal — "is this
proposed change's pipeline still running, and did it succeed or fail?"
Reconstructing that signal from the full validations list is possible but
repetitive: every integration re-implements the same aggregation and polling
logic, and each has to know which validator kinds gate a merge (the merge
mutation already encodes this, e.g. treating data-integrity validators
differently). A single status the API owns would remove that duplication and
keep external gating consistent with Infrahub's own merge rules.
Additional Information
- This is about surfacing status that already exists — the underlying
per-validator state/conclusion data is fully modelled and queryable
today. The gap is the absence of an aggregate.
- No specific shape is being prescribed (GraphQL field vs. REST endpoint, exact
enum values) — that's for whoever implements it.
Describe the Feature Request
A proposed change today exposes its check-pipeline status only in decomposed
form:
CoreProposedChange.validations→CoreValidator, where each validatorcarries its own
state(queued / in_progress / completed) andconclusion(unknown / failure / success). There is no single, first-class field that
answers "has the whole check pipeline finished, and did it pass?" for a
proposed change.
Anyone who needs the overall answer has to fetch every validation and
aggregate the
state/conclusionfields themselves, and poll that list untilall validators reach
completedbefore the conclusions are meaningful.Describe the Use Case
The staged-review workflow encourages automating the Infrahub-side review from
CI: a pipeline creates the branch, triggers the import, opens the proposed
change, and blocks the Git pull request from merging until the Infrahub checks
pass. To gate the PR, that pipeline needs one reliable signal — "is this
proposed change's pipeline still running, and did it succeed or fail?"
Reconstructing that signal from the full
validationslist is possible butrepetitive: every integration re-implements the same aggregation and polling
logic, and each has to know which validator kinds gate a merge (the merge
mutation already encodes this, e.g. treating data-integrity validators
differently). A single status the API owns would remove that duplication and
keep external gating consistent with Infrahub's own merge rules.
Additional Information
per-validator
state/conclusiondata is fully modelled and queryabletoday. The gap is the absence of an aggregate.
enum values) — that's for whoever implements it.