Gate CI/CD

Put Mirops in front of your upgrade pipeline so an unsafe cluster stops the deploy before it starts. The CLI's --enforce flag turns the verdict into an exit code.

mirops scan --source s3://my-bucket/prod.mirops --enforce
# exit 1 when decision.allow == false (CRITICAL)

Enforcement levels

Command	Fails on
mirops scan --source …	never (report only)
mirops scan … --enforce	CRITICAL (blocked)
mirops scan … --enforce --enforce-level warning	WARNING or worse

Exit codes: 0 passed · 1 gated by the verdict · 2 usage/fetch error.

GitHub Actions example

jobs:
  scan:
    runs-on: ubuntu-latest
    env:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_CLIENT_SECRET: ${{ secrets.AZURE_CLIENT_SECRET }}
    steps:
      - name: Install mirops CLI
        run: |
          mkdir -p "$RUNNER_TEMP/bin"
          curl -fsSL -o "$RUNNER_TEMP/bin/mirops" \
            https://github.com/miropshq/mirops-cli/releases/latest/download/mirops-linux-amd64
          chmod +x "$RUNNER_TEMP/bin/mirops"
          echo "$RUNNER_TEMP/bin" >> "$GITHUB_PATH"
          "$RUNNER_TEMP/bin/mirops" --version

      - name: Gate on the verdict
        run: mirops scan --source azure://myacct/reports/prod.mirops --enforce

The next stage (az aks upgrade, eksctl upgrade, …) only runs if the gate passes.

The pattern

Mirops is the gate, not the hand on the lever. Run scan before the upgrade to decide, and again after to confirm the cluster landed clean — it's the same command; the cluster state tells the story.

Environment variables

Every flag has an env-var equivalent, handy for CI:

export MIROPS_SOURCE="s3://my-bucket/prod.mirops"
export MIROPS_ENFORCE=true
mirops scan

See the CLI reference for the full list.