Skip to content

Validator Gate in CI

Intent

Run IG Publisher validation as a hard gate on every PR.

Structure

A validator gate in CI is a build pipeline stage that runs IG Publisher validation and fails PRs on conformance errors. Structurally it includes reproducible dependencies, cache controls, and a suppression governance mechanism.

  • Validation runner: scripted invocation of IG Publisher with consistent parameters
  • Dependency cache: pinned package dependencies cached safely to reduce build time without drift
  • Failure policy: what blocks merges vs what is advisory (errors vs warnings budget)
  • Suppressions: versioned suppression/known-issues files that require review and periodic cleanup
  • Artifacts: logs and reports captured so failures are diagnosable without re-running locally

Key Components

IG Publisher validation

  • Run validation on every PR
  • Fail builds on errors; budget warnings
  • Keep terminology cache consistent
  • Capture logs as build artifacts
  • Use known-issues suppression only with review

Package cache

  • Pin dependencies and cache them in CI
  • Avoid cache poisoning across branches
  • Provide a clean-cache job for debugging
  • Document cache locations and cleanup
  • Monitor cache drift as part of release process

Fail-fast rules

  • Define what failures block merging
  • Keep fail-fast suite short and fast
  • Separate advisory checks from blocking checks
  • Make error messages actionable
  • Prevent regressions by tracking recurring failures

Reviewed suppressions

  • Require justification for any suppression
  • Store suppressions in versioned files
  • Review suppressions periodically
  • Remove suppressions once upstream fixes land
  • Treat suppressions as technical debt

Behavior

Fail fast, learn faster

The behavior is to keep main green. Failures become backlog items and lead to improved automation and clearer rules.

Validator Gate in CI Sequence Diagram

On PR

  • Run validation; fail on errors; treat warnings via a defined budget.
  • Publish logs and a direct link to the failing section when possible.
  • Prevent merging until either the issue is fixed or a reviewed suppression is added.

On recurring failures

  • Identify root cause (tool upgrade, terminology drift, rule ambiguity).
  • Add regression tests/examples to prevent same class of failure.
  • Document the fix and keep suppression debt visible and time-boxed.

Benefits

  • Prevents broken packages
  • Catches FHIRPath issues

Trade-offs

  • Suppression hygiene needed

References