> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ironbee.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Running in CI

> How the action behaves on each trigger - verification scope, fix strategy, and what it reports back.

The IronBee Action adapts to what triggered the workflow: the verification scope and fix strategy change per event, and so does how results are reported back. This guide covers each trigger and the report the action produces.

***

## Pull request

```yaml theme={null}
on:
  pull_request:
    types: [opened, synchronize]
```

**Verification scope:** Diff-based reviews changed files and verifies affected pages only.

**Fix behavior:** Fixes are committed directly to the PR branch. The agent re-verifies after each fix.

**Report:** A verification report is posted as a PR comment. If the comment already exists (re-run), it is updated in place.

This is the most common trigger and the recommended starting point for most projects.

***

## Push to main

```yaml theme={null}
on:
  push:
    branches: [main]
```

**Verification scope:** Diff-based reviews the commit diff and verifies affected pages.

**Fix behavior:** If issues are found, the action creates a new branch with fixes and opens a pull request targeting `main`.

Use this alongside the PR trigger to catch anything that merged without issues but broke in context.

***

## Scheduled smoke test

```yaml theme={null}
on:
  schedule:
    - cron: '0 9 * * 1'  # Every Monday at 09:00 UTC
```

**Verification scope:** Full tests the entire application, not just changed files.

**Fix behavior:** Creates a fix PR if issues are found.

Use this for regular regression checks or to catch drift between releases. The full scope means no change is required, the agent tests every meaningful page and flow it can find.

***

## Manual verification

```yaml theme={null}
on:
  workflow_dispatch:
```

**Verification scope:** Full tests the entire application.

**Fix behavior:** Creates a fix PR if issues are found.

Trigger from the **Actions** tab in GitHub. Useful for on-demand checks before a release or after a deployment.

***

## Combining triggers

You can combine multiple triggers in one workflow:

```yaml theme={null}
on:
  push:
    branches: [main]
  pull_request:
    types: [opened, synchronize]
  schedule:
    - cron: '0 9 * * 1'
  workflow_dispatch:
```

Each trigger type uses the appropriate verification scope automatically, no additional configuration required.

***

## Trigger summary

| Trigger             | Scope | Fixes committed to   | Fix PR created |
| ------------------- | ----- | -------------------- | -------------- |
| `pull_request`      | Diff  | PR branch (directly) | No             |
| `push`              | Diff  | New fix branch       | Yes            |
| `schedule`          | Full  | New fix branch       | Yes            |
| `workflow_dispatch` | Full  | New fix branch       | Yes            |

***

## The PR report

On `pull_request` runs, the action posts a verification report as a PR comment. If a report comment already exists (a re-run on the same PR), it's updated in place rather than duplicated.

The report contains:

* **Verdict badge:** the final `pass` / `fail` / `unknown` result, with a cycle count when there was more than one.
* **Session link:** a link to the full session in the IronBee Console.
* **Per-cycle breakdown:** each verification cycle with its checks, issues, and fixes, plus a link straight to that verification in the Console.
* **Early-exit banner:** if the session ended abnormally (for example, hitting `max_turns`), a banner and a collapsible diagnostics block explain why.
* **Artifact download:** a link to the uploaded evidence bundle.

For the self-host Console host override and the structure of the evidence bundle, see [Evidence](/github-action/advanced/evidence).

***

## Fix PRs

On non-PR triggers (`push`, `workflow_dispatch`, `schedule`), there's no PR to comment on, so the same report becomes the **body of the fix PR** the action opens when verification produces changes, see the [trigger summary](#trigger-summary) above for when that happens.

***

## What's next?

<CardGroup cols={2}>
  <Card title="Verifying your application" icon="play" href="/github-action/guides/verifying-your-app">
    Configure build, start, and app URL for verification.
  </Card>

  <Card title="Verification platforms" icon="layers" href="/github-action/guides/verification-platforms">
    Verify through the browser, backend, and Node.js.
  </Card>
</CardGroup>