76 lines
3.9 KiB
Markdown
76 lines
3.9 KiB
Markdown
---
|
|
description: Summarize the latest GitHub Actions runs, surface results, and analyze issues.
|
|
argument-hint: [workflow=<file|id>|all]
|
|
allowed-tools: Edit, Bash, Grep, Read
|
|
---
|
|
|
|
# Goal
|
|
|
|
Pull the most recent GitHub Actions workflow runs for a repo, summarize their status, and analyze failures with actionable diagnostics and next steps.
|
|
|
|
# Inputs
|
|
|
|
- `$ARGUMENTS` can be:
|
|
- Optional flags:
|
|
- `workflow=<file|id>|all` (e.g., `workflow=ci.yml` or `workflow=all`; default: all workflows)
|
|
|
|
# Plan
|
|
|
|
1. **Resolve repository coordinates**
|
|
- You usually know what the current owner/repo are (often repo is the folder name).
|
|
- If `owner/repo` is unclear, infer from local git:
|
|
- Verify repo: !`git rev-parse --is-inside-work-tree`
|
|
- Remote URL: !`git remote get-url origin || git config --get remote.origin.url`
|
|
- Parse `owner` and `repo` from `https://github.com/owner/repo(.git)?` or `git@github.com:owner/repo(.git)?`.
|
|
- Find out and remember the current commit SHA using `git rev-parse HEAD`.
|
|
|
|
2. **Select workflows**
|
|
- If `workflow` not provided or set to `all`, use `gh workflow list` to enumerate available workflows.
|
|
- When calling `/flow:ci` next time, remember what those workflows are; no need to repeat unless explicitly prompted.
|
|
- Otherwise, constrain to the specified workflow file name or numeric ID.
|
|
|
|
3. **Fetch latest runs**
|
|
- For each selected workflow, use `gh run list --workflow=<workflow> --limit=<count> --json databaseId,headSha,status,conclusion,event,createdAt,updatedAt,url,name` with filters:
|
|
- `--branch=<branch>` if provided
|
|
- `--limit=<count>` (default 3, max 20)
|
|
- For each run returned, check if it refers to the current commit SHA.
|
|
- For each that does and that is completed, use `gh run view <run-id> --json status,conclusion,createdAt,updatedAt,url,event,jobs` to get more info:
|
|
- Capture status, conclusion, timings, HTML URL, job details
|
|
- If for a given workflow the run for the current commit has not yet completed, remember that but also examine the most recent completed run.
|
|
|
|
4. **Deep-dive on failures**
|
|
- For any run that has completed but with `conclusion` not `success`:
|
|
- Use `gh run view <run-id> --log-failed` to get logs for failed jobs.
|
|
- Extract dominant error patterns (stack traces, test failures, exit codes, missing secrets, flaky steps, infra timeouts).
|
|
- Map failing jobs to workflow graph where possible; note common failing steps across runs.
|
|
|
|
5. **Produce report**
|
|
- Show commit SHA prominently in the header as well as whether all runs for this commit succeeded, some failed or are still ongoing.
|
|
- **Overview table** (per workflow): run ID → commit SHA, status, conclusion, event, duration, started, link.
|
|
- Again, show the runs for the current commit, except if they are not complete, in which case also show the most revent completed run.
|
|
- **Failure summary**: frequency by job/step, top error signatures, first-seen vs. most-recent.
|
|
- **Root-cause hypotheses** per failure cluster, with **concrete next actions**:
|
|
- config fixes (matrix keys, permissions, cache keys)
|
|
- environment/toolchain diffs (runner image, Node/Java versions)
|
|
- flaky tests (test names, suggested quarantine patterns)
|
|
- secret/permission issues (missing `GITHUB_TOKEN` scopes, OIDC, org secret visibility)
|
|
- **Appendix**: tailed logs for failed jobs
|
|
|
|
6. **Output**
|
|
- Show this to the user
|
|
|
|
# Execution details
|
|
|
|
- Prefer _read-only_ operations; do **not** cancel or rerun jobs in this command.
|
|
- Be resilient to:
|
|
- Missing workflows (empty list)
|
|
- Private repos or insufficient PAT scopes (report and stop gracefully)
|
|
- Very large logs (use appropriate filtering)
|
|
- If `gh` CLI is not authenticated or configured, inform the user to run `gh auth login` first.
|
|
|
|
# Now do it
|
|
|
|
1. Gather data using the `gh` CLI commands listed above.
|
|
2. Analyze failures and suggest possible steps to mitigate.
|
|
3. Present the report to the user in the nice visual format.
|