Gh Fix Ci

Gh Fix Ci is a community skill for diagnosing and resolving continuous integration failures on GitHub Actions and similar CI platforms, covering log analysis, common failure patterns, and systematic debugging approaches for pipeline issues.

What Is This?

Overview

Gh Fix Ci provides structured approaches to identifying and resolving CI pipeline failures on GitHub. It covers workflow log retrieval and analysis, common failure pattern recognition, environment difference diagnosis, flaky test detection, and fix verification strategies. The skill turns reactive CI debugging into a systematic process with repeatable steps for the most frequent failure categories.

Who Should Use This

This skill serves developers whose pull requests fail CI checks and need fast diagnosis, DevOps engineers maintaining GitHub Actions workflows, and teams looking to reduce the time spent debugging intermittent pipeline failures that block merges.

Why Use It?

Problems It Solves

CI failures block pull requests with often cryptic error messages buried in lengthy log output. Environment differences between local development machines and CI runners cause tests that pass locally to fail in the pipeline. Flaky tests produce intermittent failures that waste developer time investigating non-reproducible issues. Dependency resolution differences between cached and fresh installs create subtle version-related breakages.

Core Highlights

Log extraction retrieves and filters relevant failure sections from verbose CI output. Pattern matching identifies common failure types including dependency conflicts, test timeouts, and environment mismatches. Diff analysis compares passing and failing runs to isolate what changed. Fix verification confirms the solution resolves the failure without introducing regressions in other workflow steps.

How to Use It?

Basic Usage

import subprocess
import json
from dataclasses import dataclass

@dataclass
class CIFailure:
    run_id: int
    job_name: str
    step_name: str
    error_lines: list[str]
    exit_code: int

def get_failed_runs(pr_number: int) -> list[dict]:
    result = subprocess.run(
        ["gh", "run", "list", "--branch", f"pr-{pr_number}",
         "--status", "failure", "--json",
         "databaseId,name,conclusion,startedAt"],
        capture_output=True, text=True
    )
    return json.loads(result.stdout)

def get_logs(run_id: int) -> str:
    result = subprocess.run(
        ["gh", "run", "view", str(run_id), "--log-failed"],
        capture_output=True, text=True
    )
    return result.stdout

def extract_errors(log_text: str) -> list[str]:
    error_markers = ["Error:", "FAILED", "error[", "AssertionError"]
    lines = log_text.split("\n")
    errors = []
    for i, line in enumerate(lines):
        if any(marker in line for marker in error_markers):
            start = max(0, i - 2)
            errors.extend(lines[start:i + 3])
    return errors

Real-World Examples

class CIDiagnostic:
    PATTERNS = {
        "dependency": ["ModuleNotFoundError", "Cannot find module",
                       "package not found", "resolution failed"],
        "timeout": ["exceeded timeout", "timed out", "Timeout"],
        "permissions": ["Permission denied", "EACCES", "403"],
        "memory": ["out of memory", "heap limit", "OOMKilled"],
        "test_failure": ["AssertionError", "FAIL ", "Expected", "assert"]
    }

    def diagnose(self, log_text: str) -> dict:
        categories = []
        for category, patterns in self.PATTERNS.items():
            for pattern in patterns:
                if pattern in log_text:
                    categories.append(category)
                    break
        return {
            "categories": categories,
            "primary": categories[0] if categories else "unknown",
            "suggestions": self._suggest(categories)
        }

    def _suggest(self, categories: list[str]) -> list[str]:
        fixes = {
            "dependency": "Check package versions and lock file consistency",
            "timeout": "Increase step timeout or optimize slow operations",
            "permissions": "Verify workflow permissions and token scopes",
            "memory": "Reduce parallel jobs or increase runner resources",
            "test_failure": "Run failing tests locally to reproduce"
        }
        return [fixes[c] for c in categories if c in fixes]

Advanced Tips

Compare the full environment output between passing and failing runs to catch version drift in system dependencies. Use workflow step caching strategically but invalidate caches when dependency files change to avoid stale package issues. Isolate flaky tests by running them repeatedly in CI to determine if failures are timing-dependent.

When to Use It?

Use Cases

Debug failing pull request checks to unblock merge workflows. Build automated triage tools that categorize CI failures and suggest fixes to developers. Monitor CI health across repositories to identify recurring infrastructure issues.

Related Topics

GitHub Actions workflow syntax, CI pipeline optimization, test reliability engineering, dependency management strategies, and build caching techniques.

Important Notes

Requirements

The GitHub CLI authenticated with repository access, permissions to view workflow runs and logs, and familiarity with the project test framework and build tooling for interpreting failure output.

Usage Recommendations

Do: check the failed step logs first rather than reading the entire workflow output. Compare recent changes against the last passing run to narrow the scope of investigation. Verify fixes by triggering a fresh CI run rather than assuming the local fix is sufficient.

Don't: retry failed runs without investigating the root cause, as intermittent success masks real issues. Modify workflow files and test code in the same commit, making it harder to isolate what resolved the failure. Disable failing tests to unblock merges without filing tracking issues.

Limitations

Log analysis can only surface errors that produce textual output and may miss silent failures. Environment-specific issues that depend on CI runner hardware or network conditions are difficult to reproduce locally. Flaky test detection requires multiple run samples that increase pipeline costs.