divyamk1234/gh-blast-radius — explained in plain English
Analysis updated 2026-05-18
Find every repository and job that depends on a specific shared GitHub Actions workflow before changing it.
Run an automatic pull request check that blocks a merge if it would break downstream consumer repos.
See which shared workflow across an organization has the widest blast radius, meaning the most consumers.
Diff two versions of a shared workflow file to find exactly which callers would break.
| divyamk1234/gh-blast-radius | 0xallam/my-recipe | 0xhassaan/nn-from-scratch | |
|---|---|---|---|
| Stars | 0 | — | 0 |
| Language | Python | Python | Python |
| Last pushed | — | 2022-11-22 | — |
| Maintenance | — | Dormant | — |
| Setup difficulty | moderate | moderate | moderate |
| Complexity | 3/5 | 2/5 | 4/5 |
| Audience | ops devops | general | developer |
Figures from each repo's GitHub metadata at analysis time.
Requires a GitHub Personal Access Token with repo scope to read workflow files across the organization.
gh-blast-radius is a command line tool and GitHub Action that answers one question for platform and developer experience teams: if I change this shared GitHub Actions workflow, what breaks. Many organizations build reusable workflows and composite actions that dozens or hundreds of other repositories depend on, but until now there was no easy way to see which repos use a shared workflow, what inputs or secrets they pass to it, or what would break if it changed. Teams often find out only after merging a change that they broke many downstream projects at once. The tool works by crawling every repository in a GitHub organization through the GitHub API and reading the workflow YAML files in each one. It parses out the inputs, secrets, and uses references in those files, then builds a directed graph connecting shared workflows to the repositories that call them, including the exact inputs each caller passes. This graph is saved locally as a JSON file, and the tool caches file contents by their SHA so later scans do not need to reread files that have not changed. Once the graph exists, several commands let you query it: scan builds or refreshes the graph, consumers lists every repository that depends on a specific shared workflow, deps shows what shared workflows a given repository depends on, stats reports which shared workflow has the widest blast radius, and diff compares two versions of a workflow file to flag exactly which consumers would break from a proposed change. The most useful setup runs gh-blast-radius as a Pull Request check inside GitHub Actions. When someone edits a shared workflow file, the action scans the organization, diffs the old and new versions, and if it finds a breaking change it posts a comment on the Pull Request naming who would be affected and fails the CI check, blocking the merge before it can break other teams' pipelines. Installation is a single pipx or uv command, and using it requires a GitHub Personal Access Token with repo scope so it can read workflow files across the organization. The project is released under the MIT license.
gh-blast-radius maps which repos depend on a shared GitHub Actions workflow and blocks pull requests that would break them.
Mainly Python. The stack also includes Python, GitHub Actions, PyYAML.
MIT license, use freely including commercially as long as the copyright notice is kept.
Setup difficulty is rated moderate, with roughly 30min to a first successful run.
Mainly ops devops.
This repo across BitVibe Labs
Verify against the repo before relying on details.