Every release triage conversation ends with 'can we just roll it back', and the answer depends on whether a migration went out with it — which is a repository question, not a CI question. Including it in the readiness analysis means the recommendation accounts for the escape route actually being available. The rest of the pipeline is the right sequence for the problem: deduplicate first so the count is real, discount known flakes so the signal is real, then correlate against the diff so causation is at least plausible. The temporal pattern detector is the unusual one and earns its place — a failure that only happens at a particular hour is a category people waste whole afternoons on before someone notices the timestamps.
A release-triage pipeline in six tools that runs in sequence: aggregate failures, score them against flakiness history, correlate them with changed files, look for time-based patterns, check rollback readiness, and produce a recommendation.
- aggregate_suite_failures parses a CI run and groups failures by error signature, deduplicating the repeats that make a failure list look worse than it is.
- cross_reference_flakiness scores each failure against a flakiness history, which is what separates a real regression from a test that fails every third Tuesday.
- correlate_code_changes matches changed files against failing tests to work out which failures the release could plausibly have caused.
- detect_temporal_failure_patterns looks at failure timestamps for chronometric patterns — the class of failure that is about time of day rather than about code.
- analyze_rollback_readiness scans for versioned database migration files, because a release with an applied migration is not one you can simply roll back.
- generate_release_recommendation combines the failures, the flakiness history and the change correlation into the actual decision.
Nothing to supply — it works on the CI output and repository you hand it.
One command — npx -y release-readiness-triage-mcp