Running in CI

The IronBee Action adapts to what triggered the workflow. The event decides what gets verified and where a fix goes. The report and the job result work the same way on every event. This guide covers each trigger and what the action produces.

Pull request

on:
  pull_request:
    types: [opened, synchronize]

What gets verified: the whole pull request. Fixes: committed to the pull request branch. Report: a comment on the pull request, updated in place on later runs. This is the most common trigger and the recommended starting point.

Push to main

on:
  push:
    branches: [main]

What gets verified: every commit in the push. Fixes: committed to a new ironbee/fix-<sha7>-<run_id> branch, with a pull request targeting the branch that was pushed. Use it alongside the pull request trigger to catch what broke after a merge.

Scheduled and manual runs

on:
  schedule:
    - cron: '0 9 * * 1'  # Every Monday at 09:00 UTC
  workflow_dispatch:

What gets verified:

On IronBee: the latest commit against its parent.
On your runner: the whole application.

Fixes: committed to a new fix branch, with a pull request. Start a manual run from the Actions tab on GitHub. It’s useful to repeat a verification after a configuration change, or before a release.

Pull request comments

on:
  issue_comment:
    types: [created]

A /ironbee-verify comment on a pull request starts a verification of that pull request. Fixes are applied only when the comment asks for them with --fix. This trigger needs a guard in the workflow, so it has its own guide: Verify from a pull request comment.

Trigger summary

Trigger	What gets verified	Fixes go to
`pull_request`	The pull request	The pull request branch
`issue_comment`	The pull request the comment is on	The pull request branch, only with `--fix`
`push`	The pushed commits	A new fix branch and pull request
`schedule`, `workflow_dispatch`	On IronBee: the latest commit. On your runner: the whole application	A new fix branch and pull request

Fixes need verification_apply_fix: true (the default) and an Anthropic credential. Without a credential, every trigger verifies and reports only. A fix whose re-verification fails is not pushed.

Combining triggers

One workflow can listen to several events. Add a concurrency group so a new push cancels the run it replaces:

on:
  push:
    branches: [main]
  pull_request:
    types: [opened, synchronize]
  schedule:
    - cron: '0 9 * * 1'
  workflow_dispatch:

concurrency:
  group: ironbee-${{ github.event.pull_request.number || github.ref }}
  cancel-in-progress: true

Turning automatic verification off

To verify only when someone asks for it by name, with a comment command or a manual dispatch, turn off verification on pushes and pull requests. You have two ways to do it. With a job-level if:. GitHub evaluates it before a runner is assigned, so a skipped event costs nothing: no runner, no checkout, no builds.

jobs:
  verify:
    if: >-
      (github.event_name != 'issue_comment' && vars.IRONBEE_VERIFICATION_AUTO != 'false') ||
      (github.event_name == 'issue_comment' &&
       github.event.issue.pull_request &&
       contains(fromJSON('["OWNER","MEMBER","COLLABORATOR"]'), github.event.comment.author_association) &&
       startsWith(github.event.comment.body, '/ironbee-verify'))

With the verification_auto input. The action resolves to “nothing to do” and the job ends green in seconds. The steps before the action, such as the checkout and your builds, still run.

- uses: ironbee-ai/ironbee-action@v1.1.0
  with:
    verification_auto: ${{ vars.IRONBEE_VERIFICATION_AUTO }}   # 'false' switches it off

Use the if: when the job does expensive setup before the action, and the input otherwise. Neither stops a comment command or a manual dispatch.

The report

The action posts the report as a pull request comment and writes it to the workflow run’s summary. When a comment from an earlier run exists, it’s updated instead of duplicated. On a push, schedule or manual run, the report becomes the body of the fix pull request. A run on IronBee reports:

the verdict and a link to the run in the IronBee Console
the summary, and the Checks, Issues and Suggested fixes from the verdict
after a fix, a link to the verification before the fix
a No verification ran or No verdict banner, with the reason, when the run couldn’t produce a verdict

A run on your runner reports:

the verdict, with the number of cycles when there was more than one
each verification cycle, with its checks, issues and fixes, and a link to that verification in the console
an early-exit banner, with a collapsible details block, when the agent stopped early (for example at claude_code_max_turns)
a link to download the evidence artifact

The job result

The last step of the action fails the job when the verification fails or ends without a verdict, so you can use the job as a required check. The verdict output (pass, fail, not_applicable or unknown) is available to later steps.

Forks

A pull request from a fork receives no secrets, so no verification can run on it. The action detects it and says so. Comment commands on fork pull requests are refused as well. See Verify from a pull request comment.

What’s next?

Verifying your application

Choose the target: an app on the runner or a deployed URL.

Verify from a comment

Start a verification with /ironbee-verify.

Integrations

GitHub Action

Pull request

Push to main

Scheduled and manual runs

Pull request comments

Trigger summary

Combining triggers

Turning automatic verification off

The report

The job result

Forks

What’s next?

Verifying your application

Verify from a comment

​Pull request

​Push to main

​Scheduled and manual runs

​Pull request comments

​Trigger summary

​Combining triggers

​Turning automatic verification off

​The report

​The job result

​Forks

​What’s next?

Verifying your application

Verify from a comment

Pull request

Push to main

Scheduled and manual runs

Pull request comments

Trigger summary

Combining triggers

Turning automatic verification off

The report

The job result

Forks

What’s next?