fetch-ci-build

name	fetch-ci-build
description	Fetch CI build results and diagnose failures. Auto-detects provider from project files or URLs. Supports GitHub Actions, Buildkite, and CircleCI.

Fetch CI Build

Overview

Fetch CI build results, diagnose failures, extract actionable error information, and suggest fixes. Supports multiple CI providers with automatic detection.

Supported Providers

Provider	Detection	Tool
GitHub Actions	.github/workflows/ or github.com URL	gh CLI
Buildkite	.buildkite/ or buildkite.com URL	bk CLI
CircleCI	.circleci/ or circleci.com URL	Python script

Auto-Detection

From URL

If the user provides a CI URL, detect provider:

• github.com/.../actions/runs/... → GitHub Actions
• buildkite.com/... → Buildkite
• app.circleci.com/... or circleci.com/... → CircleCI

From Project Files

Check for CI configuration directories:

# GitHub Actions
test -d .github/workflows && echo "github"

# Buildkite
test -d .buildkite && echo "buildkite"

# CircleCI
test -d .circleci && echo "circleci"

Workflow

digraph workflow {
    rankdir=TB;
    node [shape=box];
    
    detect [label="1. Detect CI provider"];
    load [label="2. Load provider reference"];
    fetch [label="3. Fetch build results"];
    check [label="4. Check for failures" shape=diamond];
    passed [label="Report: Build passed!"];
    read [label="5. Read failing source files"];
    present [label="6. Present failures + proposed fixes"];
    ask [label="7. Ask: Apply fix?" shape=diamond];
    apply [label="Apply the fix"];
    next [label="Next failure?" shape=diamond];
    done [label="Done"];
    
    detect -> load;
    load -> fetch;
    fetch -> check;
    check -> passed [label="passed"];
    check -> read [label="failed"];
    read -> present;
    present -> ask;
    ask -> apply [label="yes"];
    ask -> next [label="no"];
    apply -> next;
    next -> read [label="yes"];
    next -> done [label="no"];
}

Step-by-Step Process

1. Detect CI Provider

First, check if the user provided a URL. If not, detect from project files.

2. Load Provider Reference

Read the appropriate reference file for provider-specific commands:

• GitHub: references/github.md
• Buildkite: references/buildkite.md
• CircleCI: references/circleci.md

3. Fetch Build Results

Use the provider-specific commands to fetch build information and failures.

For Buildkite, prefer bk CLI as the primary path (not the legacy Python helper script).

4. For Each Failure

Read the relevant source file to understand context:

• For test failures: read the test file at the indicated line
• For lint errors: read the source file at the indicated line
• For TypeScript errors: read the file and understand the type issue

5. Present Findings and Propose Fix

Show the user:

• What failed (test name, file, line)
• Error message
• Proposed fix based on the error

6. Ask User What To Do

Ask how to proceed:

• "Apply the suggested fix"
• "Investigate further before fixing"
• "Skip this failure"

Error Types Detected

Type	Detection	Common Fixes
Test failure	Minitest/RSpec/Jest/pytest output	Fix assertion, update expected value, fix test setup
Lint error	Rubocop/ESLint/Biome violations	Auto-fix with linter's fix command
TypeScript	TSC compilation errors	Add types, fix type mismatches
Build error	Compilation failures	Fix syntax, missing dependencies

Common Mistakes

Mistake	Solution
Can't detect provider	Specify provider explicitly or provide CI URL
Missing credentials	Check provider reference for required env vars/auth
Build still running	Wait for completion or check partial results
Buildkite path still using old script	Use references/buildkite.md bk workflow first; only fall back to API/script if bk is unavailable
Rate limiting	Wait and retry