doomer / ai
DocsSign In

Run reviews in CI

Start with a repository identity, choose GitHub Actions or Depot, and run the same adversaries on every pull request.

Prefer reviews without a workflow?

Install the GitHub App from Repos, turn on repositories, and Doomer reviews new and updated pull requests with hosted inference. No workflow file or repository model key. Use this CI path when you choose the adversaries, bring your own provider key, or need OIDC review feedback memory.

Hosted reviews

GitHub Actions

Add a pull-request workflow, GitHub review permissions, and an artifact cache.

Setup guide

Depot workflows

Run on Depot, trust the Depot organization identity, and mount a persistent cache disk.

Setup guide

Before you add the workflow

Both providers use the same three pieces. Set them up once, then copy the provider workflow.

  1. 1. Trust the CI identity

    Open your project's CI / OIDC settings, choose the provider, and trust one repository or an organization. Use Pull access for reviews.

  2. 2. Choose authentication

    Prefer OIDC: it exchanges each job identity for a short-lived, repository-bound token. Use a service account only when your CI cannot issue a supported OIDC identity.

  3. 3. Add model and cache settings

    Store the model provider key as a CI secret. Persist the action's data-dir so later runs reuse pulled adversaries.

OIDC or service account?

OptionUse it whenWhat to configure
OIDC (recommended)GitHub Actions or native Depot workflows.A project trust rule, id-token: write, auth-mode: oidc, and your project slug.
Service accountOIDC is unavailable or a generic CI runner performs the review.A token with registry:pull, stored as a CI secret, plus auth-mode: token.

Repository feedback memory is repository-bound and requires OIDC. A service account can pull and run adversaries, but it cannot load or register that review feedback memory.

Plan for the first run

A new repository has no artifact cache, so the first automatic review may pull many packages. Configure the provider's persistent cache and set the action's timeout-minutes to at least 20. Warm runs reuse immutable package digests; workflows without a persistent cache pay the cold-start cost on every run.

Publishing instead?

Publishing needs a separate push-capable trust grant and should run only from a trusted branch or tag—not a pull-request workflow.

Publish adversaries