Mobile CI/CD release gate integration

Guardian in CI is the same CLI, invoked by your pipeline, running inside the runner you already control. There is no Guardian service in the path and nothing to authenticate against.

The execution model

Analysis runs in your runner, on the checkout that is already there.
No source, artefact or report is sent to a Guardian service.
No account, token or API key is involved in a scan.
The report is a file in your workspace until your pipeline moves it.

What blocks a build

Two commands do the work. guardian scan produces findings and a report; guardian release check produces the decision. In a pipeline you usually want both: the report as evidence, the check as the gate.

The gate, in two commands

guardian scan . \
  --format sarif \
  --output guardian-report.sarif \
  --baseline guardian-baseline.json \
  --fail-on-new

guardian release check

--fail-on-new with a committed baseline is what makes a gate adoptable on an existing codebase. Without it, day one blocks on the entire backlog and the gate gets switched off by the end of the week.

Templates

Every Guardian command below appears in the bundled CLI’s help output. The installation step does not: no public installation route has been published, so each template marks that step instead of inventing a registry, package name, URL or token. Replace the marked line with your approved installation step.

Generic shell

Commands verified

The portable form. Every other template is this, wrapped in a provider’s syntax.

guardian-gate.sh

#!/usr/bin/env bash
set -euo pipefail

# TODO: install Guardian here. No public installation route is published yet.
# Replace this line with your approved installation step.

guardian version
guardian detect .

# Fail on findings this change introduced, not on the existing backlog.
guardian scan . \
  --format sarif \
  --output guardian-report.sarif \
  --baseline guardian-baseline.json \
  --fail-on-new

# The release decision. Non-zero exit stops the pipeline.
guardian release check

GitHub Actions

Template only

SARIF is the format GitHub code scanning ingests. The upload step is GitHub’s, not Guardian’s.

.github/workflows/guardian.yml

name: Guardian release gate
on: [pull_request]

permissions:
  contents: read
  security-events: write

jobs:
  guardian:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # TODO: install Guardian here. No public installation route is
      # published yet. Replace this step with your approved installation.
      - name: Install Guardian
        run: exit 1

      - name: Detect project
        run: guardian detect .

      - name: Scan and gate on new findings
        run: |
          guardian scan . \
            --format sarif \
            --output guardian-report.sarif \
            --baseline guardian-baseline.json \
            --fail-on-new

      - name: Release check
        run: guardian release check

      - name: Keep the report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: guardian-report
          path: guardian-report.sarif

GitLab CI

Template only

The GitLab report format exists in the CLI. How a given GitLab version consumes it is your side of the contract, so verify it against your instance.

.gitlab-ci.yml

guardian:
  stage: test
  script:
    # TODO: install Guardian here. No public installation route is
    # published yet. Replace this line with your approved installation step.
    - exit 1
    - guardian detect .
    - guardian scan .
        --format gitlab
        --output guardian-report.json
        --baseline guardian-baseline.json
        --fail-on-new
    - guardian release check
  artifacts:
    when: always
    paths:
      - guardian-report.json

Bitrise

Template only

Bitrise stacks already carry the mobile toolchain, which usually means better coverage than a minimal Linux image.

bitrise.yml

workflows:
  guardian:
    steps:
      - activate-ssh-key@4: {}
      - git-clone@8: {}
      - script@1:
          title: Guardian release gate
          inputs:
            - content: |
                #!/usr/bin/env bash
                set -euo pipefail

                # TODO: install Guardian here. No public installation route
                # is published yet. Replace this with your approved step.
                exit 1

                guardian detect .
                guardian scan . \
                  --format html \
                  --output "$BITRISE_DEPLOY_DIR/guardian-report.html" \
                  --baseline guardian-baseline.json \
                  --fail-on-new
                guardian release check
      - deploy-to-bitrise-io@2: {}

Jenkins

Template only

Keep the gate in its own stage so a failure is legible in the pipeline view.

Jenkinsfile

pipeline {
  agent any
  stages {
    stage('Guardian') {
      steps {
        // TODO: install Guardian here. No public installation route is
        // published yet. Replace this with your approved installation step.
        sh 'exit 1'

        sh 'guardian detect .'
        sh '''
          guardian scan . \
            --format json \
            --output guardian-report.json \
            --baseline guardian-baseline.json \
            --fail-on-new
        '''
        sh 'guardian release check'
      }
    }
  }
  post {
    always {
      archiveArtifacts artifacts: 'guardian-report.json',
                       allowEmptyArchive: true
    }
  }
}

Reports as artefacts

Keep the report when the build fails, not only when it passes — a failed gate is exactly when someone needs to read why. Every template above preserves the report unconditionally.

SARIF suits code-scanning systems that ingest it directly, which is why the GitHub template uses it.
HTML suits a human reviewer who will not open a pipeline log.
JSON suits your own tooling.
Reports can contain file paths and project structure. Apply the same retention and access rules you apply to build logs.

Reports and formats covers each one in detail, andtroubleshooting covers the failures that are specific to pipelines.