GitHub Workflow Integration
Use a dedicated reliability gate job in pull requests and mark it as a required status check in repository branch protection rules.
.github/workflows/sepurux-gate.yml
name: Sepurux Reliability Gate
on:
pull_request:
workflow_dispatch:
jobs:
reliability-gate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.11"
- name: Install Sepurux CLI
run: pip install sepurux
- name: Run reliability gate
run: |
sepurux run campaign \
--project my-agent \
--campaign core-reliability \
--min-reliability 80 \
--timeout 600 \
--api-key ${{ secrets.SEPURUX_API_KEY }}
env:
SEPURUX_API_BASE_URL: https://app.sepurux.dev/api/backend
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
GITHUB_REPO: ${{ github.repository }}
PR_NUMBER: ${{ github.event.pull_request.number }}CI API Flow
For custom CI systems, call the CI endpoints directly and decide pass/fail from the returned decision payload.
bash
# 1) create CI run
curl -X POST https://app.sepurux.dev/api/backend/v1/ci/runs \
-H "Content-Type: application/json" \
-H "X-Sepurux-Token: $CI_TOKEN" \
-d '{
"trace_id": "<trace_uuid>",
"campaign_id": "<campaign_uuid>",
"thresholds": {
"min_pass_rate": 0.85,
"max_unsafe": 0,
"max_failures": 0,
"min_reliability_score": 80
},
"repo": "sepurux/sepurux-platform",
"pull_request_number": 42
}'
# 2) poll CI decision
curl -X GET https://app.sepurux.dev/api/backend/v1/ci/runs/<run_uuid> \
-H "X-Sepurux-Token: $CI_TOKEN"Decision Model
A CI run returns `pass`, `fail`, or `pending`. You should block deploy on `fail` and continue polling while `pending`.
json
{
"run_id": "...",
"status": "done",
"decision": "fail",
"pass_rate": 0.72,
"unsafe_attempts": 1,
"failures": 5,
"top_failing_tools": [
{"tool": "payments.refund", "count": 3}
],
"dashboard_url": "https://app.sepurux.dev/runs/..."
}Rollout Tips
Use a staged enforcement model so teams adopt reliability gating without breaking delivery velocity.
Week 1
Observe only: report scores and failure tools, but do not block merges.
Week 2
Soft gate: require review when reliability falls below threshold.
Week 3+
Hard gate: block merge/deploy when decision is fail.