/
/
Know within minutes whether a deploy broke your Ghost Inspector tests
For developers and QA teams who want before and after test results around a GitHub deploy, by asking their AI assistant.
On this page
Connector
Connect GitHub, pick your AI tool and paste the prompt.
The problem
Post deploy test checks get skipped after busy releases
After a deploy, someone compares Ghost Inspector results before and after it to see what broke. Lining test times up against the GitHub run and working out what shipped is slow, so after a busy release it is often skipped.
Without PopdockAI
- Find the deploy run times in GitHub
- Compare Ghost Inspector results either side
- Work out which commits shipped
- Skip it when the release day is busy
With PopdockAI
- The latest successful run and the one before set the windows
- Each test is sorted as regressed, fixed, still failing or not run
- Regressions come with their failing step
- Shipped commits and a verdict close the report, nothing changed
The prompt
Use this prompt
Copy it into any AI tool connected to PopdockAI. Swap the values in braces for your own.
**Objective:** Find Ghost Inspector tests that passed before the latest successful run of the GitHub workflow `{workflow-name}` (branch `{branch}`, or any if blank) and have failed since.
**Step 1: Find the deploy (GitHub)**
Call `github-get-workflow-run` with `name` set to `{workflow-name}`, `conclusion` success, and `branch` set to `{branch}` if given. Take the most recent run by `updated-date` and treat its `updated-date` as the deploy time. If there is none, stop.
Call `github-get-workflow-run` again for the previous successful run of the same workflow, to bound the before window.
**Step 2: Compare results (Ghost Inspector)**
Call `ghost-inspector-get-test-result` twice: once with `date-created.from` set to the previous deploy and `date-created.to` set to the deploy time (before), and once with `date-created.from` set to the deploy time (after). Group by `test-id` and take the latest result per test in each window.
* **Regressed**: passing before, failing after.
* **Fixed**: failing before, passing after.
* **Still failing**: failing in both.
* **Not run since**: had a result before, none after.
**Step 3: Detail the regressions (Ghost Inspector, then GitHub)**
For each regressed test, call `ghost-inspector-get-test-step` with its after `test-result-id` and `passing` false for the failing step. Then call `github-get-commit` with `commit-date.from` set to the previous deploy and `commit-date.to` set to the deploy time to list what shipped.
**Step 4: Report**
* The deploy: workflow, run number, branch, short sha, time, url.
* Regressed tests first (name, suite, failing step command and target), then Fixed, Still failing and Not run since as counts with names.
* The commits that shipped in the deploy.
* A verdict: whether the deploy looks clean or introduced regressions.
**Rules & Guidelines:**
* `github-get-workflow-run` and `github-get-commit` are on the github server; the ghost-inspector tools are on the ghost-inspector server.
* This prompt is read-only. Do NOT call `ghost-inspector-execute-suite`, `ghost-inspector-execute-test`, `github-rerun-workflow-run` or `github-add-issue`.
**Validation:**
* If no tests ran after the deploy, say the deploy is untested and suggest running the relevant suite; do not run it.
* Compare times in UTC; if either side has no zone, widen the boundary by one hour and say so.Who it's for
One answer, three teams that use it
Developers
Check your deploy did not break tests
Regressions come with the failing step and the commits that shipped.
Did the latest Deploy staging run in GitHub cause any Ghost Inspector regressions?
Release managers
Get a verdict after each deploy
A clear verdict tells you whether to roll back or move on.
Check the last Release workflow on main for Ghost Inspector regressions and give me a verdict.
QA engineers
See which tests a deploy fixed
Tests that went from failing to passing are listed alongside the regressions.
Which Ghost Inspector tests did the latest Deploy production run fix or break on the release branch?
How it works
What PopdockAI does when you ask
You name the workflow and optionally a branch, and your AI assistant compares test results either side of the deploy. It says plainly when the deploy was untested.
01
Ask
You name the GitHub workflow and optionally a branch.
02
Find
It finds the latest successful run and the one before it to set the windows.
03
Compare
It sorts each Ghost Inspector test as regressed, fixed, still failing or not run since.
04
Report
You get a verdict, the failing steps and the commits that shipped.
What PopdockAI provides
The tools behind the answer
Ready made tools for GitHub and one secure connection to your AI tool. No code, no exports.
github-get-workflow-run
ghost-inspector-get-test-result
ghost-inspector-get-test-step
github-get-commit
This report is built from Get data tools only. PopdockAI applies the row, field and parameter rules your admin sets, and every query is written to the audit trail.
The outcome
Know within minutes if a deploy broke anything
Related use cases
More ways to put this data to work
One prompt template with infinite possibilities.
Your AI assistant adapts its approach, tone, and capabilities to match each unique context while you maintain a single, manageable workflow.
Join forward-thinking companies that are transforming their operations with intelligent, secure AI automation.

.webp)
