CI/CD Integration

Trigger AegisRunner scans and test runs from any CI pipeline — GitHub Actions, GitLab CI, CircleCI, Jenkins, anything that can make an HTTP request. This guide walks through setting up a token, the trigger payload, language-specific examples, and the GitHub PR comment integration.

How it works

1. Generate a project-scoped CI trigger token from the project page.
2. Store the token as a CI secret.
3. POST to /api/v1/ci/trigger with the token in the Authorization header.
4. The endpoint queues the run and returns a run ID. You can poll for completion or pass wait: true and let the request block.
5. Optionally, AegisRunner posts a sticky comment on the GitHub PR when the run finishes.

Generating a token

1. Open the project, click the Integrations tab.
2. Click the CI/CD sub-tab.
3. Click Create Token, give it a name (e.g. "GitHub Actions — main branch").
4. Copy the token immediately. It's shown once and only once.
5. Add it to your CI provider's secret store (e.g. AEGIS_CI_TOKEN in GitHub Actions secrets).

Tokens are project-scoped — a token for project A can't trigger runs in project B. Tokens have no expiry by default but can be revoked from the same screen.

The trigger endpoint

POST /api/v1/ci/trigger
Authorization: Bearer aegis_<token>
Content-Type: application/json

Request body

Response

{
  "runId": "019e4...",
  "status": "queued",
  "runType": "manual",
  "url": "https://aegisrunner.com/runs/019e4..."
}

GitHub Actions example

name: AegisRunner
on:
  pull_request:
    branches: [main]

jobs:
  aegis-tests:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger AegisRunner run
        run: |
          curl -fsSL -X POST https://aegisrunner.com/api/v1/ci/trigger \
            -H "Authorization: Bearer aegis_${{ secrets.AEGIS_CI_TOKEN }}" \
            -H "Content-Type: application/json" \
            -d '{
              "crawl": true,
              "baseUrl": "https://pr-${{ github.event.pull_request.number }}.preview.example.com",
              "wait": true,
              "githubRepo": "${{ github.repository }}",
              "githubPrNumber": ${{ github.event.pull_request.number }},
              "githubCommitSha": "${{ github.event.pull_request.head.sha }}",
              "githubToken": "${{ secrets.GITHUB_TOKEN }}"
            }'

With wait: true, the curl call exits non-zero if the run fails — your pipeline fails as expected.

GitLab CI example

aegis-tests:
  stage: test
  image: alpine:latest
  before_script:
    - apk add --no-cache curl
  script:
    - |
      curl -fsSL -X POST https://aegisrunner.com/api/v1/ci/trigger \
        -H "Authorization: Bearer aegis_$AEGIS_CI_TOKEN" \
        -H "Content-Type: application/json" \
        -d "{
          \"baseUrl\": \"$CI_ENVIRONMENT_URL\",
          \"crawl\": true,
          \"wait\": true
        }"
  only:
    - merge_requests

Polling for status

If you don't pass wait: true, the trigger returns immediately. Poll the status endpoint:

GET /api/v1/ci/runs/<runId>
Authorization: Bearer aegis_<token>

Returns the run's status, pass/fail counts, duration, and a link to the run page. Common pattern: a CI step that polls every 10 seconds for up to 10 minutes, exiting non-zero if the run failed or didn't finish.

GitHub PR comments

When you include githubRepo, githubPrNumber, and githubToken, AegisRunner posts a sticky comment on the PR after the run completes. The comment includes:

• Pass/fail summary with counts.
• Link to the run page.
• Top failing tests (if any), with one-line failure reasons.
• Visual regression diffs if any were rejected.

The comment is sticky — re-running on the same PR updates the existing comment rather than spamming new ones.

Commit status checks

When you also pass githubCommitSha, AegisRunner publishes a commit status (aegisrunner) that turns the green checkmark in the PR view into a red X if the run fails. Combine with branch protection rules to block merges on failure.

Smart test selection

For large suites, running everything on every PR gets expensive. Use selectionStrategy to run only the tests that matter:

• changed — run tests covering the files changed in the PR (requires git diff payload).
• flaky — run only known-flaky tests, useful for stability sweeps.
• recent — run tests created or edited in the last N days.

See Smart Test Selection.

Environment variables in scripts

Login scripts and tests can reference values from Test Environment → Tokens with {{TOKEN_NAME}} syntax. CI can override these per-trigger by passing them in environmentId (Pro+) or directly via the trigger payload.

Plan limits

Common questions

Related

• Deployment Webhooks — auto-trigger on Vercel / Netlify / GitLab deploys.
• Smart Test Selection — run fewer tests per PR.
• Baseline Replays — deterministic CI runs.
• Notifications & Alerts — get failures into Slack on top of PR comments.