github-actions-logs
GitHub Actions 워크플로우 로그를 조회하고 분석합니다. "CI 로그 확인해줘", "워크플로우 실패 원인 분석해줘", "GitHub Actions 상태 알려줘", "빌드 로그 보여줘", "테스트 실패 로그 확인" 등을 요청할 때 활성화됩니다.
When & Why to Use This Skill
This Claude skill enables seamless integration with GitHub Actions to retrieve, monitor, and analyze workflow logs directly within the chat interface. By leveraging the GitHub CLI, it empowers developers to quickly diagnose CI/CD pipeline failures, inspect build logs, and identify root causes of test regressions, significantly accelerating the debugging process and improving development velocity.
Use Cases
- Root Cause Analysis: Automatically fetch and analyze logs from failed GitHub Actions runs to pinpoint specific errors like compilation failures, linting issues, or dependency conflicts.
- CI Status Monitoring: Check the real-time status of workflows for specific commits or branches to ensure code quality before merging pull requests.
- Test Failure Debugging: Extract and summarize failed test cases and assertion errors from large log files without manually navigating the GitHub UI.
- Workflow Management: List recent workflow runs and trigger reruns for failed jobs directly through natural language commands.
| name | github-actions-logs |
|---|---|
| description | > |
GitHub Actions 로그 조회 스킬
개요
이 스킬은 GitHub Actions 워크플로우의 로그를 조회하고 분석하는 방법을 제공합니다. CI/CD 파이프라인의 실패 원인을 빠르게 파악하고, 문제를 해결하는 데 도움을 줍니다.
실행 조건
다음과 같은 요청 시 이 스킬이 활성화됩니다:
- "CI 로그 확인해줘"
- "워크플로우 실패 원인 분석해줘"
- "GitHub Actions 상태 알려줘"
- "빌드 로그 보여줘"
- "테스트 실패 로그 확인"
- "CI 왜 실패했어?"
사전 조건
- GitHub CLI (
gh)가 설치되어 있어야 합니다 (SessionStart hook에서 자동 설치) GITHUB_TOKEN또는GH_TOKEN환경 변수가 설정되어 있어야 합니다- Git 저장소가 GitHub에 연결되어 있어야 합니다
중요: 프록시 환경 지원
SessionStart hook이 자동으로 gh.repo git config를 설정합니다.
모든 gh 명령어는 다음과 같이 실행해야 합니다:
GH_REPO=$(git config --get gh.repo) gh <명령어>
예시:
GH_REPO=$(git config --get gh.repo) gh run list --limit 5
사용 가능한 명령어
1. 최근 워크플로우 실행 목록 조회
gh run list --limit 10
출력 예시:
STATUS TITLE WORKFLOW BRANCH EVENT ID ELAPSED AGE
✓ fix: update deps CI main push 1234567890 2m30s 5m
✗ feat: new feature CI dev push 1234567889 1m45s 10m
2. 특정 워크플로우 실행 상세 정보 조회
gh run view <run-id>
또는 최근 실패한 워크플로우:
gh run view $(gh run list --status failure --limit 1 --json databaseId --jq '.[0].databaseId')
3. 워크플로우 Jobs 목록 조회
gh run view <run-id> --json jobs --jq '.jobs[] | {name: .name, status: .status, conclusion: .conclusion}'
4. 실패한 Job의 로그 조회
gh run view <run-id> --log-failed
이 명령은 실패한 step의 로그만 출력합니다.
5. 전체 로그 조회
gh run view <run-id> --log
주의: 전체 로그는 매우 길 수 있습니다.
6. 특정 Job의 로그만 조회
gh run view <run-id> --job <job-id> --log
7. 현재 커밋의 워크플로우 상태 확인
# 현재 HEAD 커밋의 워크플로우 조회
COMMIT_SHA=$(git rev-parse HEAD)
gh api "repos/{owner}/{repo}/actions/runs?head_sha=$COMMIT_SHA" --jq '.workflow_runs[] | {name: .name, status: .status, conclusion: .conclusion, url: .html_url}'
문제 해결 가이드
워크플로우가 실패했을 때
실패한 워크플로우 확인
gh run list --status failure --limit 5실패 원인 분석
gh run view <run-id> --log-failed상세 로그 확인 (필요한 경우)
gh run view <run-id> --log
일반적인 실패 원인
테스트 실패
- 로그에서
FAIL,Error,AssertionError등을 검색 - 실패한 테스트 케이스 이름 확인
- 예상값과 실제값 비교
빌드 실패
- 컴파일 에러 메시지 확인
- 의존성 설치 실패 여부 확인
- Node.js/Python 버전 호환성 확인
린트 실패
- ESLint, Prettier 등의 에러 메시지 확인
- 자동 수정 가능 여부:
npm run lint:fix
타임아웃
- 워크플로우 실행 시간 확인
- 무한 루프나 느린 테스트 확인
API를 통한 상세 조회
워크플로우 실행 정보
gh api repos/{owner}/{repo}/actions/runs/{run_id}
Jobs 목록
gh api repos/{owner}/{repo}/actions/runs/{run_id}/jobs
Job 로그 다운로드
gh api repos/{owner}/{repo}/actions/jobs/{job_id}/logs
예시 시나리오
시나리오 1: CI가 실패했을 때 원인 파악
# 1. 최근 실패한 워크플로우 확인
gh run list --status failure --limit 1
# 2. 실패 로그 확인
gh run view <run-id> --log-failed
# 3. 실패한 step 분석
# 로그에서 에러 메시지를 찾아 원인 파악
시나리오 2: 특정 커밋의 CI 상태 확인
# 현재 커밋의 워크플로우 상태
COMMIT=$(git rev-parse HEAD)
gh run list --commit $COMMIT
시나리오 3: 워크플로우 재실행
# 실패한 워크플로우 재실행
gh run rerun <run-id>
# 실패한 job만 재실행
gh run rerun <run-id> --failed
출력 형식
JSON 출력 (스크립트용)
gh run list --json status,conclusion,name,databaseId --limit 5
필터링된 출력
gh run list --json status,name --jq '.[] | select(.status == "failure") | .name'
주의사항
- 토큰 권한:
repo및actions:read권한이 필요합니다 - API 제한: GitHub API에는 rate limit이 있으므로 과도한 요청을 피하세요
- 로그 크기: 전체 로그는 매우 클 수 있으므로
--log-failed옵션을 우선 사용하세요 - 비공개 저장소: 적절한 인증이 필요합니다