Handling CI failure
This guide gives an overview of how Runbooks agents auto-fix CI failures. Runbooks agents currently can only fix failure in pull requests generated by Runbooks.
Detecting CI failure
Runbooks framework automatically track any CI failures on the pull requests that are generated by Runbooks. Once the in-flight and queued steps are completed, Runbooks agents start monitoring the CI status checks of the commit SHA.
A few things to note:
If there are multiple PRs generated by Runbooks, all PRs are monitored for CI status check.
Runbooks only tracks the latest head commit SHA for each PR.
If latest head commit SHA is added manually (not be Runbooks), CI is not monitored.
If a new commit gets added in middle of the CI validation workflow, the CI rework workflow is terminated.
Runbooks will monitor all CI checks that are reported in GitHub and will work through only the first failed status check among one of the supported CI (see below).
Rework config
By default, Runbooks agents will attempt fixing the CI 2 times. This property can be updated via Runbooks Config > Pull Requests > CI Failure Auto-Rework.
For every attempt, Runbooks agents will also publish a summary as a GitHub comment.
Supported CI
To understand the CI failure reason, Runbooks agents analyze the CI logs
GitHub workfows
GitHub workflows are natively supported and no additional permissions are required.
Buildkite
To access Buildkite logs, you must provide the Buildkite API token through the Workspace integrations page:
Step 1: Go to “Personal Settings” from the top-right corner
Step 2: Click “API Access Tokens”
Step 3: Click “New API Access Token”
Name the token and pick your organization
Choose “Read Artifacts”, “Read Builds”, “Read Build logs”, and “Read Pipelines”.
Click “Create New API Access Token”
Step 4: Copy the created access token, and go to https://app.aviator.co/settings/workspace/integrations, paste the created access token to the Buildkite integration.
Last updated
Was this helpful?