CI/CD

Run midcore gates run (and optionally agent tasks) in your CI pipeline so every merge passes the same checks and evidence is recorded.

Running gates in CI

Install the Midcore CLI in your job, then run gates from the project root. Exit code 0 means all gates passed; non-zero means at least one failed. Use that to fail the pipeline.

GitHub Actions

# Example: run gates on every push to main
jobs:
  gates:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Midcore CLI
        run: curl -fsSL https://get.midcore.dev/install.sh | bash
      - name: Run gates
        run: midcore gates run
        env:
          # Set any required env vars for your gates (e.g. API URL, auth)
          MIDCORE_API_URL: ${{ secrets.MIDCORE_API_URL }}

GitLab CI

# Example: run gates in a GitLab CI job
gates:
  stage: test
  image: ubuntu:22.04
  before_script:
    - apt-get update && apt-get install -y curl
    - curl -fsSL https://get.midcore.dev/install.sh | bash
  script:
    - midcore gates run
  variables:
    # Set any required env vars (use CI/CD variables in GitLab)
    MIDCORE_API_URL: $MIDCORE_API_URL

Environment variables

Store API keys, tokens, and API base URLs in your CI platform's secrets (e.g. GitHub Secrets, GitLab CI/CD variables). Pass them into the job so midcore gates run and any gate scripts can use them. Never commit secrets. See Environment variables.

Optional: running the agent in CI

You can run the agent in CI for automated tasks (e.g. "fix lint", "update deps"). Use non-interactive flags if your CLI supports them, and ensure the job has enough time and resources. For most teams, running only gates in CI is enough; use the agent locally or in a separate workflow.

Exit codes

0 = success. Non-zero = failure. Configure your CI to fail the job on non-zero exit. See CLI reference and Troubleshooting.

Optional: HTTP smoke checks

If your pipeline brings up the API container (or hits a staging URL), add a minimal check that the process responds and still publishes a spec—without embedding any proprietary payloads:

curl -fsS "${API_BASE}/health"
curl -fsS "${API_BASE}/openapi.json" | head -c 1  # non-empty response

For how the web app proxies to the same API in production, see Web app & API proxies and OpenAPI & interactive docs.

CLI reference · Environment variables · Troubleshooting (CI)