Pipelines

The examples use damdit.yml in the repository and keep its state folder between runs, so each run reports what is new since the one before.

GitHub Actions

Save the key as the repository secret DAMDIT_CI_KEY, then add .github/workflows/damdit.yml:

name: Damdit
on:
  schedule: [{ cron: "0 6 * * 1" }] # every Monday at 06:00 UTC
  workflow_dispatch:
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # The last run of each website is the baseline of the next one.
      - uses: actions/cache@v4
        with:
          path: damdit-state
          key: damdit-${{ github.run_id }}
          restore-keys: damdit-
      - run: docker run --rm -e DAMDIT_CI_KEY -v "$PWD:/work" damdit/damdit run
        env:
          DAMDIT_CI_KEY: ${{ secrets.DAMDIT_CI_KEY }}
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: damdit-reports
          path: damdit-state/*/reports/

The job fails when a website hits its failOn. The reports are attached to the run as an artifact.

After a deploy

To audit right after a deployment, run the same steps in the job that deploys, after the deploy step. For a preview deployment, audit its address with audit and the pages that changed:

- run: |
    docker run --rm -e DAMDIT_CI_KEY damdit/damdit \
      audit "$PREVIEW_URL" --urls "$PREVIEW_URL/,$PREVIEW_URL/pricing/"
  env:
    DAMDIT_CI_KEY: ${{ secrets.DAMDIT_CI_KEY }}
    PREVIEW_URL: https://preview.example.com

Other CI systems

Any runner that can start a Docker container with a mounted folder works the same way: pass DAMDIT_CI_KEY from the CI’s secret store, mount the working folder at /work and keep damdit-state/ between runs with the CI’s cache.

Good to know

• Each audit loads the website like a visitor. A firewall or bot protection may block CI addresses; see damdit.com/bot for what to allow.
• An audit of a large website can take 10–30 minutes. Give the job enough time.
• Each audit counts toward the account’s 200 a day.