DocsBook a demo

Platform

Platform overviewArchitectureWorkflow orchestrationGitOps configurationGovernance and AAAAI and MCPKnowledge and contextRuntime and executionEvidence and monitoring

Use cases

All use casesProduction incidentRelease preparationHotfix to productionSecurity scan triage
Why NopsAIIntegrationsSecurity

Resources

All resourcesAI agent governanceMCP governanceMCP securitySelf-hosted platforms
PricingGitHub

Company

How a run worksAboutContactBook a demo

Conditions and failure handling

Skipping work that does not apply, and deciding which failures should stop a run.

ReferenceAutomation authorOperator

Key points

  • condition is a natural-language question evaluated by the model against run context; it is rejected when llm_enabled: false.
  • A false condition normally skips the step, but under blocking guardrail or policy context it fails closed instead.
  • ignore_failure lets the graph continue past a failed step, and the run finishes warning rather than failure.
  • Step ignore_failure also applies to every task in the step; a task can set its own.
  • An ignored failure stays auditable as failure (ignored) — it is not hidden.
  • Approval failures and explicit policy or guardrail enforcement failures still fail closed, whatever ignore_failure says.

Examples

What this page addsyaml
  - name: announce
    depends_on: [package]
    condition: Only run when the release channel is stable.
    ignore_failure: true
    script: |
      ./scripts/announce.sh
Pipeline so faryaml
name: release-service
description: Build, verify, and publish the payments service.
container_image: alpine:3.20
working_directory: /workspace
timeout: 45m
variables:
  - RELEASE_CHANNEL
  - platform/shared:ARTIFACT_BUCKET
steps:
  - name: build
    script: |
      make build
      echo "1.0.$(date +%s)" > /nopsai/outputs/BUILD_TAG
    outputs:
      - name: BUILD_TAG

  - name: verify
    image: golang:1.24
    depends_on: [build]
    runtime_pool: ci
    volumes:
      - build-cache:/root/.cache
    script: |
      go vet ./...
      go test ./...

  - name: checks
    depends_on: [verify]
    tasks:
      - name: licenses
        ignore_failure: true
        script: |
          ./scripts/license-check.sh
      - name: sbom
        script: |
          ./scripts/sbom.sh > /workspace/sbom.json
          sha256sum /workspace/sbom.json | cut -d' ' -f1 > /nopsai/outputs/SBOM_DIGEST
        outputs:
          - name: SBOM_DIGEST
      - name: report
        depends_on: [checks.licenses, checks.sbom]
        variables:
          SBOM_DIGEST: $steps.checks.sbom.outputs.SBOM_DIGEST
        script: |
          echo "checks complete"
          echo "sbom $SBOM_DIGEST"

  - name: package
    depends_on: [checks]
    secrets:
      - REGISTRY_TOKEN
      - platform/shared:SIGNING_KEY
    variables:
      BUILD_TAG: $steps.build.outputs.BUILD_TAG
    script: |
      ./scripts/package.sh "$BUILD_TAG"
      echo "channel $RELEASE_CHANNEL, bucket $ARTIFACT_BUCKET"
      ./scripts/mint-token.sh > /nopsai/outputs/PUBLISH_TOKEN
      ./scripts/sign.sh --key "$SIGNING_KEY" --token "$REGISTRY_TOKEN"
    outputs:
      - name: PUBLISH_TOKEN
        sensitive: true

  - name: announce
    depends_on: [package]
    condition: Only run when the release channel is stable.
    ignore_failure: true
    script: |
      ./scripts/announce.sh
Result

A failing licence check or a failing announcement now leaves the run warning; everything else still fails the run.

Rejected: a condition with the LLM disabledyaml
llm_enabled: false
steps:
  - name: announce
    condition: Only run on the stable channel.
    script: ./scripts/announce.sh
Result

Rejected: condition requires an LLM-enabled pipeline.

Field reference

steps[].conditionstepstringOptionalNone

Natural-language condition evaluated by the LLM before the step runs.

Example

condition: Only run when the changed files include a migration.

Rules
  • Rejected when llm_enabled: false.
  • A false result normally skips the step; under blocking guardrail or policy context it fails closed instead.
Evidence

services/nopsai/pkg/validation/pipeline.go

steps[].ignore_failurestepbooleanOptionalfalse

Treat failures in this step as ignored so the graph can continue. The run finishes with status warning instead of failure.

Example

ignore_failure: true

Rules
  • Also applies to every task in the step.
  • Ignored failures stay auditable as failure (ignored).
  • Approval failures and explicit policy or guardrail enforcement failures still fail closed.
tasks[].ignore_failuretaskbooleanOptionalStep `ignore_failure`, otherwise false

Treat this task failure as ignored. The run finishes with status warning.

Example

ignore_failure: true

Rules
  • Approval and explicit policy or guardrail enforcement failures still fail closed.

How it works

These two directives answer different questions. condition asks whether the work applies to this run at all; ignore_failure asks whether the work failing should stop everything else.

warning exists so a run that did its job but lost a best-effort side task is not reported the same way as a run that failed to build. Treat a warning run as a real signal, not a green one.

Because a condition is model-evaluated, write it as a question about the run, not as an expression. "Only run when the changed files include a migration" is a condition; a boolean expression over variables is not what this directive is.

Implementation evidence

  • services/nopsai/pkg/validation/pipeline.go

    Rules the validator enforces on this directive set.

  • doc/runtime-flows.md

    Step skipping, ignored failures, and run status resolution.