Fleet 1.13:Teams are now shipping 5x more PRs with autonomous pipelines.See what's new →
FleetFleet
Integration

Fleet + CI/CD: Branch Protection Enforces CI; Fleet's Gate Checks Review Approval

Fleet does not run CI, and its merge gate does not read CI check results. The Go merge gate behind fleet release check <pr> evaluates review-approval signals only: it returns mergeable when a reviewer's pr_approved fabric event plus an approved label are present, or when GitHub's reviewDecision is APPROVED — and not superseded by a later pr_changes_requested. It does not inspect whether your CI checks passed or failed.

Enforcing failing CI as a hard merge blocker is the job of GitHub branch protection, not Fleet's gate. Configure required status checks on your branch and GitHub itself will block the merge until they pass; Fleet's release-manager performs the actual merge through the gh CLI, so a branch-protection failure surfaces as a refused merge. Fleet never starts CI jobs. (ci_required is honored by the release-manager skill as a convention, not parsed by the Go binary — and even there it does not make the gate read check results.)

Setup

1

Ensure your CI posts check results to GitHub on each PR

# Standard behavior for GitHub Actions, CircleCI, Buildkite, etc.
# No Fleet-specific configuration needed
2

Require those checks via GitHub branch protection so failing CI blocks the merge

# GitHub repo → Settings → Branches → Branch protection rule
# Enable "Require status checks to pass before merging"
3

The release-manager agent runs the review-approval gate before merging

fleet release check 42

What you gain

  • With GitHub branch protection requiring status checks, a failing CI run blocks the merge that the release-manager attempts through the gh CLI
  • Fleet's release-manager merges only after the review-approval gate passes, and every gate decision lands in the fabric event log for traceability
  • Any CI that writes GitHub check results integrates with this flow through GitHub branch protection — no CI-specific configuration in Fleet

Honest limits

  • Fleet does not run, trigger, or orchestrate CI, and its merge gate does not read CI check results at all
  • Enforcing failing CI as a merge blocker depends on GitHub branch protection, not Fleet's gate — without it, the gate evaluates review approval only
  • Fleet reads the GitHub check status via the gh CLI for visibility, but it does not integrate with CI dashboards, artifact stores, or test-report viewers

Frequently asked questions

Can Fleet trigger a CI run?

Not directly. Fleet pushes a branch and opens a PR, which triggers CI the normal GitHub way. Fleet does not call CI APIs to start jobs, and it does not run CI itself.

Does `fleet release check` block a merge when CI is red?

No. The Go merge gate reads review-approval signals only — a pr_approved fabric event plus an approved label, or a GitHub APPROVED reviewDecision — and does not inspect CI check results. To block merges on failing CI, use GitHub branch protection with required status checks; GitHub then refuses the merge the release-manager attempts via the gh CLI.

Run your first agent fleet

One binary. Five minutes. See every agent, coordinate every handoff, and keep a full audit trail of what your fleet did.