341 lines
9.9 KiB
Plaintext
341 lines
9.9 KiB
Plaintext
---
|
|
title: "GitHub Issue RCA Sample"
|
|
description: "Automated GitHub issue analysis using Cline CLI to identify root causes."
|
|
---
|
|
|
|
Automated GitHub issue analysis using Cline CLI. This script uses Cline's autonomous AI capabilities to fetch, analyze, and identify root causes of GitHub issues, outputting clean, parseable results that can be easily integrated into your development workflows.
|
|
|
|
<Note>
|
|
**New to Cline CLI?** This sample assumes you have already completed the [Installation Guide](https://docs.cline.bot/getting-started/installing-cline) and authenticated with `cline auth`. If you haven't set up Cline CLI yet, please start there first.
|
|
</Note>
|
|
|
|
<Frame>
|
|
<img src="https://storage.googleapis.com/cline_public_images/cli-rca.gif" alt="CLI Root Cause Analysis Demo" width="600" />
|
|
</Frame>
|
|
|
|
## Prerequisites
|
|
|
|
This sample assumes you have already:
|
|
|
|
- **Cline CLI** installed and authenticated ([Installation Guide](https://docs.cline.bot/getting-started/installing-cline))
|
|
- **At least one AI model provider** configured (e.g., OpenRouter, Anthropic, OpenAI)
|
|
- **Basic familiarity** with Cline CLI commands
|
|
|
|
Additionally, you'll need:
|
|
|
|
- **GitHub CLI** (`gh`) installed and authenticated
|
|
- **jq** installed for JSON parsing
|
|
- **bash** shell (or compatible shell)
|
|
|
|
### Installation Instructions
|
|
|
|
#### macOS
|
|
|
|
<Note>
|
|
These instructions require [Homebrew](https://brew.sh/) to be installed. If you don't have Homebrew, install it first by running:
|
|
```bash
|
|
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
|
|
```
|
|
</Note>
|
|
|
|
```bash
|
|
# Install GitHub CLI
|
|
brew install gh
|
|
|
|
# Install jq
|
|
brew install jq
|
|
|
|
# Authenticate with GitHub
|
|
gh auth login
|
|
```
|
|
|
|
#### Linux
|
|
|
|
```bash
|
|
# Install GitHub CLI (Debian/Ubuntu)
|
|
sudo apt install gh
|
|
|
|
# Or for other Linux distributions, see: https://cli.github.com/manual/installation
|
|
|
|
# Install jq (Debian/Ubuntu)
|
|
sudo apt install jq
|
|
|
|
# Authenticate with GitHub
|
|
gh auth login
|
|
```
|
|
|
|
## Getting the Script
|
|
|
|
**Option 1: Download directly with curl**
|
|
```bash
|
|
curl -O https://raw.githubusercontent.com/cline/cline/main/src/samples/cli/github-issue-rca/analyze-issue.sh
|
|
```
|
|
|
|
**Option 2: Copy the full script**
|
|
|
|
<Accordion title="Click to view the complete analyze-issue.sh script">
|
|
|
|
```bash
|
|
#!/bin/bash
|
|
# Analyze a GitHub issue using Cline CLI
|
|
|
|
if [ -z "$1" ]; then
|
|
echo "Usage: $0 <github-issue-url> [prompt]"
|
|
echo "Example: $0 https://github.com/owner/repo/issues/123"
|
|
echo "Example: $0 https://github.com/owner/repo/issues/123 'What is the root cause of this issue?'"
|
|
exit 1
|
|
fi
|
|
|
|
# Gather the args
|
|
ISSUE_URL="$1"
|
|
PROMPT="${2:-What is the root cause of this issue?}"
|
|
# Ask Cline for its analysis, showing only the summary
|
|
cline --auto-approve true --json "$PROMPT: $ISSUE_URL" | \
|
|
jq -r 'select(.type == "agent_event" and .event.type == "done") | .event.text' | \
|
|
sed 's/\\n/\n/g'
|
|
```
|
|
|
|
</Accordion>
|
|
|
|
<Note>
|
|
**After downloading or creating the script**, make it executable by running:
|
|
```bash
|
|
chmod +x analyze-issue.sh
|
|
```
|
|
</Note>
|
|
|
|
## Quick Usage Examples
|
|
|
|
### Basic Usage
|
|
|
|
Run this command in your terminal from the directory where you saved the script to analyze an issue with the default root cause prompt:
|
|
|
|
```bash
|
|
./analyze-issue.sh https://github.com/owner/repo/issues/123
|
|
```
|
|
|
|
This will:
|
|
- Fetch issue #123 from the repository
|
|
- Analyze the issue to identify root causes
|
|
- Provide detailed analysis with recommendations
|
|
|
|
### Custom Analysis Prompt
|
|
|
|
Ask specific questions about the issue:
|
|
|
|
```bash
|
|
./analyze-issue.sh https://github.com/owner/repo/issues/456 "What is the security impact?"
|
|
```
|
|
|
|
<Note>
|
|
The script will automatically handle everything: fetching the issue, analyzing it with Cline, and displaying the results. The analysis typically takes 30-60 seconds depending on the issue complexity.
|
|
</Note>
|
|
|
|
## How It Works
|
|
|
|
Let's analyze each component of the script to understand how it works.
|
|
|
|
### Argument Validation
|
|
|
|
The script validates input and provides usage instructions:
|
|
|
|
```bash
|
|
if [ -z "$1" ]; then
|
|
echo "Usage: $0 <github-issue-url> [prompt]"
|
|
echo "Example: $0 https://github.com/owner/repo/issues/123"
|
|
echo "Example: $0 https://github.com/owner/repo/issues/123 'What is the root cause?'"
|
|
exit 1
|
|
fi
|
|
```
|
|
|
|
**Key Points:**
|
|
- Validates required GitHub issue URL
|
|
- Shows clear usage examples
|
|
- Supports optional custom prompt
|
|
|
|
### Argument Parsing
|
|
|
|
The script extracts and sets up the arguments:
|
|
|
|
```bash
|
|
# Gather the args
|
|
ISSUE_URL="$1"
|
|
PROMPT="${2:-What is the root cause of this issue?}"
|
|
```
|
|
|
|
**Explanation:**
|
|
- `ISSUE_URL="$1"` - First argument is always the issue URL
|
|
- `PROMPT="${2:-...}"` - Second argument is optional, defaults to root cause analysis
|
|
- The SDK CLI runs the task directly, so no address flag is required.
|
|
|
|
### The Core Analysis Pipeline
|
|
|
|
This is where the magic happens:
|
|
|
|
```bash
|
|
# Ask Cline for its analysis, showing only the summary
|
|
cline --auto-approve true --json "$PROMPT: $ISSUE_URL" | \
|
|
jq -r 'select(.type == "agent_event" and .event.type == "done") | .event.text' | \
|
|
sed 's/\\n/\n/g'
|
|
```
|
|
|
|
<Accordion title="Pipeline Breakdown: Understanding Each Component">
|
|
|
|
**1. `cline --auto-approve true --json "$PROMPT: $ISSUE_URL"`**
|
|
- `cline` is the Cline CLI binary
|
|
- Act mode is the default for prompt runs
|
|
- `--auto-approve true` allows tool use without interactive prompts
|
|
- `--json` emits newline-delimited JSON for parsing
|
|
- Constructs prompt with issue URL
|
|
|
|
**2. `jq -r 'select(.type == "agent_event" and .event.type == "done") | .event.text'`**
|
|
- Filters for the final agent `done` event
|
|
- Extracts the final text field
|
|
- `-r` outputs raw strings (no JSON quotes)
|
|
|
|
**3. `sed 's/\\n/\n/g'`**
|
|
- Converts escaped newlines to actual newlines
|
|
- Makes output readable
|
|
|
|
</Accordion>
|
|
|
|
## Sample Output
|
|
|
|
Here's an example analyzing a real Flutter issue:
|
|
|
|
```bash
|
|
$ ./analyze-issue.sh https://github.com/csells/flutter_counter/issues/2
|
|
```
|
|
|
|
**Output:**
|
|
|
|
```markdown
|
|
**Root Cause Analysis of Issue #2: "setState isn't cutting it"**
|
|
|
|
After examining the GitHub issue and analyzing the Flutter counter codebase,
|
|
I've identified the root cause of why setState() is insufficient for this
|
|
project's needs:
|
|
|
|
## Current Implementation Problems
|
|
|
|
The current Flutter counter app uses setState() for state management, which
|
|
has several limitations:
|
|
|
|
1. **Local State Only**: setState() only works within a single widget, making
|
|
it difficult to share state across the app
|
|
2. **Rebuild Overhead**: Every setState() call rebuilds the entire widget tree,
|
|
causing performance issues with complex UIs
|
|
3. **No State Persistence**: State is lost when the widget is disposed
|
|
4. **Testing Challenges**: setState-based logic is tightly coupled to the UI,
|
|
making unit testing difficult
|
|
|
|
## Why This Matters
|
|
|
|
As the app grows beyond a simple counter, these limitations become critical:
|
|
- Multiple screens need to access the count
|
|
- State needs to persist across navigation
|
|
- Business logic should be testable independently
|
|
- UI should only rebuild when necessary
|
|
|
|
## Recommended Solutions
|
|
|
|
The issue mentions "Provider or Bloc" - both are excellent alternatives:
|
|
|
|
1. **Provider**: Simple, lightweight state management using InheritedWidget
|
|
- Easy migration path from setState
|
|
- Good for small to medium apps
|
|
- Official Flutter recommendation
|
|
|
|
2. **Bloc**: More structured approach with clear separation between events,
|
|
states, and business logic
|
|
- Better for complex apps
|
|
- Excellent testability
|
|
- Clear architectural patterns
|
|
|
|
3. **Riverpod**: Modern alternative to Provider with better performance and
|
|
developer experience
|
|
- Compile-time safety
|
|
- Better testing support
|
|
- More flexible than Provider
|
|
|
|
4. **GetX**: Full-featured solution with state management, routing, and
|
|
dependency injection
|
|
- Minimal boilerplate
|
|
- Fast and lightweight
|
|
- All-in-one solution
|
|
|
|
## Next Steps
|
|
|
|
The current codebase needs refactoring to implement proper state management
|
|
architecture to handle more complex state scenarios effectively. Provider
|
|
would be the easiest migration path while Bloc provides better long-term
|
|
scalability.
|
|
```
|
|
|
|
## When to Use This Pattern
|
|
|
|
This script pattern is ideal for various development scenarios where automated GitHub issue analysis can accelerate your workflow.
|
|
|
|
### Bug Investigation
|
|
|
|
Quickly analyze bug reports and identify root causes without manual code exploration:
|
|
|
|
```bash
|
|
./analyze-issue.sh https://github.com/project/repo/issues/123 \
|
|
"What is the root cause of this bug?"
|
|
```
|
|
|
|
### Feature Request Analysis
|
|
|
|
Understand context and implications of feature requests:
|
|
|
|
```bash
|
|
./analyze-issue.sh https://github.com/project/repo/issues/456 \
|
|
"What are the implementation challenges?"
|
|
```
|
|
|
|
### Security Audits
|
|
|
|
Assess security implications of reported issues:
|
|
|
|
```bash
|
|
./analyze-issue.sh https://github.com/project/repo/issues/789 \
|
|
"What are the security implications?"
|
|
```
|
|
|
|
### Documentation Generation
|
|
|
|
Generate detailed technical documentation from issues:
|
|
|
|
```bash
|
|
./analyze-issue.sh https://github.com/project/repo/issues/654 \
|
|
"Provide detailed technical documentation for this issue"
|
|
```
|
|
|
|
### Code Review Assistance
|
|
|
|
Get second opinions on proposed changes:
|
|
|
|
```bash
|
|
./analyze-issue.sh https://github.com/project/repo/issues/987 \
|
|
"Review the proposed solution approach"
|
|
```
|
|
|
|
## Conclusion
|
|
|
|
This sample demonstrates how to build an autonomous GitHub issue analysis tool using Cline CLI:
|
|
|
|
1. **Building autonomous CLI tools** using Cline's capabilities
|
|
2. **Parsing structured JSON output** from Cline CLI
|
|
3. **Creating flexible automation scripts** with custom prompting
|
|
4. **Integrating with GitHub** for issue analysis
|
|
5. **Handling command-line arguments** effectively
|
|
|
|
This pattern can be adapted for many other automation scenarios, from pull request reviews to documentation generation to code quality analysis.
|
|
|
|
## Related Resources
|
|
|
|
- [CLI Installation Guide](https://docs.cline.bot/getting-started/installing-cline)
|
|
- [CLI Reference Documentation](https://docs.cline.bot/cli/cli-reference)
|
|
- [Headless Mode](https://docs.cline.bot/usage/cli-overview#headless-mode)
|