Add a GitHub Actions workflow that fails a PR when an incident label is set but no valid Incident Card is included.
Validate an Incident Card file locally before pushing it in a pull request.
Get inline GitHub code scanning annotations pointing at the exact invalid line in an Incident Card.
Configure which services and labels are allowed so validation matches a team's own incident process.
| balyakin/incident-ci | 0xhassaan/nn-from-scratch | 3ks/embedoc | |
|---|---|---|---|
| Stars | 0 | 0 | — |
| Language | Python | Python | Python |
| Last pushed | — | — | 2023-06-08 |
| Maintenance | — | — | Dormant |
| Setup difficulty | easy | moderate | hard |
| Complexity | 2/5 | 4/5 | 1/5 |
| Audience | ops devops | developer | developer |
Figures from each repo's GitHub metadata at analysis time.
Requires Python 3.12 and the uv package manager, add a .incident-ci.yaml config to define required labels and allowed services.
This project is a small command line tool and GitHub Action that enforces one rule: if a pull request is about a production incident, it must include a properly filled out Incident Card before it can be merged. An Incident Card is a Markdown file that contains a single YAML block describing the incident, things like its id, severity, which service was affected, who is the commander, when it was detected, mitigated, and resolved, and links to logs. Rather than tracking this information in Slack threads or a PR description where it is easy to skip and hard to review, the tool keeps the record inside the repository itself, so it gets reviewed and diffed the same way as code. In a pull request, the tool can look at which files changed and which labels are on the PR to decide whether an Incident Card is actually required. If a required label like "incident" is missing, the check passes without demanding a card. If the label is present but no valid card was added or updated, the check fails. Results can be printed as plain text, JSON, or a SARIF report, and the SARIF format is designed to plug into GitHub's code scanning feature so problems show up as annotations directly on the file and line that failed. The validation rules go beyond just checking that a YAML block exists. They check field types, timestamp ordering, and required text lengths, and they enforce extra conditions depending on severity, for example high and critical incidents must name a commander and describe impact, and critical incidents must include a link to logs. The service named in the card must also be one of the values allowed in a project's own configuration file. The repository includes a ready to use GitHub Actions workflow file that runs this check automatically whenever a pull request is opened, edited, or has its labels changed, and uploads the SARIF report so failures appear as inline GitHub annotations. The author describes this as an intentionally minimal first version: a stateless command line tool and composite GitHub Action, with no web interface, API server, database, or background worker. It targets Python 3.12 and its own test suite requires at least 90 percent coverage.
A CLI and GitHub Action that blocks pull requests about production incidents from merging unless they include a valid, structured Incident Card file.
Mainly Python. The stack also includes Python, Pydantic, GitHub Actions.
No license information is provided in the README.
Setup difficulty is rated easy, with roughly 30min to a first successful run.
Mainly ops devops.
This repo across BitVibe Labs
Verify against the repo before relying on details.