Skip to main content

​
Overview

On every interactive launch OpenSRE asks which demo to run. The recommended option analyzes a real repository from your machine and reports CI/CD reliability KPIs, including the developer time lost to unreliable CI. That analysis is read-only and takes a couple of minutes. The other choices set up a recurring CI/CD agent, show the upcoming managed service, or connect Slack. Press Escape to skip, or use the custom-answer row to type a different request. Run it again at any time with /demo, or by asking:

​
Prerequisites

  • git on PATH
  • A GitHub token that can read Actions history (opensre integrations setup github, or GITHUB_TOKEN)

​
What happens

The agent guides you through the selected demo in the shell.
  1. Scan. It scans your home directory for git checkouts and paints a bar chart of the last 30 days of commits, your own contributions first.
  2. Pick a repository. A menu lists your checkouts that have GitHub Actions workflows, then the open-source example, then a row to type your own.
  3. Analyze. It reads the repository’s Actions history for the last 30 days and paints the report: one sentence on what waiting on CI cost, the key results, then a comparison table against langchain-ai/langchain and anomalyco/opencode. The benchmark columns ship with OpenSRE and name the day they were measured. Every analysis reads GitHub; nothing is answered from a cache.
  4. Next step. A menu offers the CI reliability agent (it schedules the check for the repository you just analyzed, no second repository question), the Slack hand-off, or exit.
Typing a request such as analyze owner/repo CI/CD performance for the last 30 days skips the scan and repository picker.

​
The KPIs

Only PRs that were merged count toward blocked time, so the number reflects delays that sat on the path to a real merge. Workflows that fail and recover in parallel on the same commit count once, a commit’s wait ends when the next commit of the same PR is pushed or the PR merges, and a commit whose workflows never all passed is left out. A later commit that triggered no workflow is invisible; the merge time still bounds the wait. When GitHub omits a PR number, the run belongs to the first later merge of that head repository and branch. When it attaches several, the run belongs to the merged PR whose lifetime contains the run. Developer downtime is the part of each wait that falls inside working hours: Monday to Friday, 09:00 to 18:00 in this machine’s timezone, printed with the figure. A re-run that happened over a weekend adds wall-clock wait but no downtime. Each blocked PR is attributed to its author, so the report can say how many hours a week the heaviest-hit developers lost. The report shows the calculation, not only its result. It states the formula (expected green = first run queued + normal duration; blocked = actually green minus expected green, in working hours), then a table of the most blocked PRs with their author, queue time, normal duration, expected and actual green times, and the working-hours and wall-clock wait, then the sum across all blocked PRs, the division by the developers affected, the per-week figure, and the heaviest-hit developers. The wall-clock total across PRs not merged yet is shown when it differs.

​
The CI reliability agent

Pick “Set up an agent that improves CI/CD reliability over time” from the startup menu to analyze the repository now, then schedule that report as a recurring check. The demo scans your machine, asks which repository to watch, reads GitHub Actions (a token is required), and creates the loop (weekdays at 08:00 local time by default). Choosing this option after an analytics report schedules that repository without asking you to pick it again. Every later run analyzes the last 7 days; use /loops run <id> to run it now.
  • Reports land in this shell’s inbox: /loops messages. The loop never posts to Slack or any chat channel, even when those integrations are configured.
  • Manage it with /loops list, /loops stop <id>, and /loops delete <id>.
  • Each run is deterministic: no model turn sits between the schedule and the report, and the raw figures are saved as JSON next to the report path named at the end of every delivery, under ~/.opensre/ci_reliability_reports/.
  • The loop fires while the shell is open. To keep it running when the shell is closed, run /loops service install; it installs a per-user service (launchd on macOS, systemd on Linux) that starts at login. /loops service remove deletes it. Windows is not supported yet; run opensre cron start --service from Task Scheduler instead.
  • Running the demo again for the same repository reuses the existing loop.

​
Limits

  • Windows up to 90 days. Each scope reads at most 2,000 runs; the report says so when a cap was hit.
  • Merged PR detection covers the 500 most recently updated closed PRs.
  • Scheduled and manually dispatched workflows count toward executions but not toward default-branch red time.

​
Troubleshooting