Why
Failing CI builds block other work from landing, but hub has no way to surface them today — you'd need to check each CI provider separately.
Current state
hub status shows PRs and issues only. There is no CI workflow type in the config schema. Multiple CI providers are in use across contexts (GitHub Actions for personal projects, CodeFresh at work), so the design must support both without conflating them.
Ideal state
- CI failures appear in
hub status's unified ranked list alongside PRs, issues, and other items — no dedicated CI section
- Each entry shows: repo, workflow/pipeline name, conclusion, age, and URL to the failing run
- The workflow config is provider-namespaced:
ci-github-actions and ci-codefresh are distinct hub.toml entries with separate client implementations
- Failures from all configured providers appear together in the unified list, sorted by
(urgency, age)
- When all configured runs are passing, no CI items appear
Out of scope
- Re-running failed CI from hub
- Showing passing or queued runs
Starting points
clients/src/github.rs — pattern for a GitHub-sourced client to follow for ci-github-actions
config/src/toml.rs — where WorkflowConfig variants are defined
workflows/src/status.rs — StatusItem enum where new CiFailure variants are added; run() where they're collected and sorted
QA plan
- Add a
ci-github-actions workflow entry to hub.toml for a repo with a failing Actions run
- Run
hub status — expect a CI failure item in the unified list, sorted above lower-urgency items
- Fix the failing run so it passes, re-run
hub status — expect the entry disappears
- Add a
ci-codefresh entry for a repo with a failing Codefresh pipeline, run hub status — expect both providers' failures appear together in the unified list
- Remove all CI workflow entries from
hub.toml — expect no CI items appear
Done when
hub status shows failing CI runs from at least one provider (GitHub Actions or CodeFresh) for configured repos.
Why
Failing CI builds block other work from landing, but hub has no way to surface them today — you'd need to check each CI provider separately.
Current state
hub statusshows PRs and issues only. There is no CI workflow type in the config schema. Multiple CI providers are in use across contexts (GitHub Actions for personal projects, CodeFresh at work), so the design must support both without conflating them.Ideal state
hub status's unified ranked list alongside PRs, issues, and other items — no dedicated CI sectionci-github-actionsandci-codefreshare distincthub.tomlentries with separate client implementations(urgency, age)Out of scope
Starting points
clients/src/github.rs— pattern for a GitHub-sourced client to follow forci-github-actionsconfig/src/toml.rs— whereWorkflowConfigvariants are definedworkflows/src/status.rs—StatusItemenum where newCiFailurevariants are added;run()where they're collected and sortedQA plan
ci-github-actionsworkflow entry tohub.tomlfor a repo with a failing Actions runhub status— expect a CI failure item in the unified list, sorted above lower-urgency itemshub status— expect the entry disappearsci-codefreshentry for a repo with a failing Codefresh pipeline, runhub status— expect both providers' failures appear together in the unified listhub.toml— expect no CI items appearDone when
hub statusshows failing CI runs from at least one provider (GitHub Actions or CodeFresh) for configured repos.