Continuous testing for pull requests
Build confidently. Deploy safely. Know what broke.
DevSentinel AI connects your GitHub pull requests to TestSprite test runs and ties every result to the exact commit it tested, so you always know which change passes, which fails, and whether a fix has landed.
The pull request testing workflow
- 1
Open a PR on a connected repository
- 2
GitHub delivers a signed webhook
- 3
Signature verified; job queued (deduped)
- 4
TestSprite runs through the official CLI
- 5
Result bound to the head commit SHA
- 6
Status published to the same SHA
Results never carry over to a new commit. When the head moves, earlier runs are marked Stale, and a status is published only after the head SHA is re-checked.
What DevSentinel AI does
Automated pull request testing
Every pull request triggers a TestSprite test run through the official CLI. A run is reported as passed only after the provider confirms it.
Results bound to the exact commit
Each run is permanently bound to the commit SHA it tested. When a new commit lands, earlier results are marked Stale and can never validate the new head.
Secure deployment monitoring
Check a deployed URL on a schedule. Requests to internal addresses, cloud metadata endpoints, and reserved ranges are blocked, and health is reported only after a completed check.
Evidence-backed incidents
Incidents open automatically from verified events, such as threshold breaches and failed runs on the current head, and keep a full evidence timeline.
Transparent integration status
Each integration shows whether it is configured and healthy, so you always know what is connected.
AI-assisted investigation
An optional assistant separates confirmed facts, each linked to its evidence, from hypotheses and open questions.
Security and privacy
- Server-side authentication and authorization on every route; cross-user access returns 404.
- GitHub webhooks are verified with HMAC-SHA256 over the raw body, constant-time, before parsing; deliveries are deduplicated by delivery ID.
- TestSprite and GitHub credentials are encrypted with AES-256-GCM and shown write-only (last four characters at most).
- Run output is size-capped and passed through a central secret-redaction utility before storage.
- Monitoring performs no requests to loopback, private, link-local, CGNAT, or reserved ranges — including DNS-resolved addresses and redirect targets.
- Passwords use scrypt with per-user salts; sessions are httpOnly cookies with idle and absolute timeouts.
FAQ
What does it test?
Pull requests on connected GitHub repositories are tested through TestSprite frontend test runs against your deployed target URL. Each run is executed by TestSprite and labeled accordingly.
Does it deploy anything?
No. DevSentinel observes deployments via HTTP checks. It does not deploy or manage infrastructure.
How is my data handled?
Credentials are encrypted at rest (AES-256-GCM) and write-only in the UI. Run output is capped, truncated visibly, and redacted for common secret patterns.
What do I need to set up?
A DevSentinel account, a GitHub repository you control, a TestSprite account with an API key (and a project ID), plus a reachable webhook endpoint. Optional: GitHub token for commit statuses, an AI provider key for investigations.