Fix Ci

If Failed.count == 0 and all checks passed — report success, stop.

1c. Fetch all CI checks

Use gh pr checks text format (tab-separated) — it reliably includes Azure URLs unlike the JSON statusCheckRollup where detailsUrl can be null.

gh pr checks $PR 2>&1

Output format (tab-separated):

CheckName\tstatus\tduration\tURL

Parse and classify each check:

• pass — succeeded
• fail — failed
• pending — still running

Group checks by source:

• Azure Pipelines — URL contains dev.azure.com. Extract buildId from first Azure URL. These are the test jobs.
• GitHub Actions — URL contains github.com/actions. These include build (compilation), gitleaks (secret scanning), Danger (PR linting). Failed GitHub Actions checks are relevant — report them.
• Other — CodeRabbit (no URL or review-only) — skip.

Extract buildId from the first Azure URL (all checks in one pipeline run share the same buildId).

1d. Report non-Azure failures

For each failed GitHub Actions check, fetch its details:

# Extract run_id and job_id from URL: https://github.com/{owner}/{repo}/actions/runs/{run_id}/job/{job_id}
gh run view {run_id} --json jobs --jq '.jobs[] | select(.conclusion == "failure") | {name, conclusion}'

Report these as Category E (non-test failures) in the final output. Common cases:

• Danger — PR convention issues (title format, description, labels). Show the comment: gh pr view $PR --comments --jq '.comments[-1].body'
• build — compilation failure. The job log contains the error.
• gitleaks — secret detected in diff.

1e. Triage

• All passed + summary shows 0 failures — report success, stop.
• Some failed — proceed to Step 2 with failed checks. Report summary: "24 test failures across 14 runs out of 279K tests."
• All pending, none failed — report "CI still running, no failures yet. Re-run this command later or use /loop 2m /fix-ci $PR to monitor."
• Mix of pending + failed — proceed with failed checks immediately. Don't wait for the full run.
• Only non-Azure checks failed (e.g., Danger, build) — report those directly, skip Steps 2-3.

Step 2: Get failed test names (no auth, no log download)

Use the Azure Test Results microservice at vstmr.dev.azure.com. This is a different hostname from the build APIs and serves test result data publicly for public projects.

curl -s "https://vstmr.dev.azure.com/questdb/questdb/_apis/testresults/resultsbybuild?buildId={buildId}&publishContext=CI&outcomes=Failed&\$top=200&api-version=5.2-preview.1"

No authentication or special headers needed. Returns all failed test results (~1-5KB):

[
  {
    "automatedTestName": "test[/sql/sample_by_fill.test]",
    "automatedTestStorage": "io.questdb.test.sqllogictest.SqlTest",
    "outcome": "Failed",
    "runId": 795795,
    "durationInMs": 1067.0,
    "id": 100001,
    "testCaseTitle": "test[/sql/sample_by_fill.test]"
  }
]

Key fields:

• automatedTestName / testCaseTitle — the test name
• automatedTestStorage — the test class (e.g., io.questdb.test.sqllogictest.SqlTest)
• runId — which CI job run this failure came from
• outcome — always "Failed" given the filter

Deduplicate by test name — the same test fails across multiple platforms (mac, windows, linux). Group by automatedTestName, collect runIds to know which platforms failed.

If this returns 0 results but Step 1b showed failures, fall back to Step 2b (log tail parsing). This can happen if the pipeline doesn't publish JUnit test results.

2a (optional). Enrich with error messages via PAT

The vstmr endpoint returns test names but NOT errorMessage, stackTrace, or computerName. If AZURE_DEVOPS_PAT is set, enrich each failed test with full details.

Step 2 gives us runId per failed test. Use the authenticated test/runs/{runId}/results endpoint to get error details:

# For each unique runId from Step 2:
curl -s -u ":$AZURE_DEVOPS_PAT" \
  -H "X-TFS-FedAuthRedirect: Suppress" \
  "https://dev.azure.com/questdb/questdb/_apis/test/runs/{runId}/results?outcomes=Failed&api-version=7.0"

This returns full details per failed test:

• errorMessage — the assertion failure or exception message
• stackTrace — full Java stack trace
• automatedTestName, automatedTestStorage — test identity
• failingSince — when this test started failing
• failureType — type of failure

With this data, skip directly to Step 4 (classification).

Note: test/runs?buildId=... (listing runs by build) requires Build: Read scope and returns 403 with Test Management: Read alone. But test/runs/{runId}/results works with just Test Management: Read — and we already have runIds from the unauthenticated Step 2.

If no PAT is set, suggest the user create one for richer failure data:

To get error messages and stack traces without downloading logs, set AZURE_DEVOPS_PAT:

1. Go to https://dev.azure.com/questdb/_usersSettings/tokens
2. Click "New Token"
3. Set scope: Test Management → Read (the only scope needed)
4. Add to ~/.zshenv: export AZURE_DEVOPS_PAT=<token>

Without it, I can still see which tests failed but need to download log tails for error details.

Only suggest this once per session, and only if log tail parsing is actually needed (i.e., the test names alone aren't enough for classification).

2b. Fallback: log tail parsing (no auth)

Use this when Step 2 returns 0 results or when error messages are needed and no PAT is available.

Parse Azure URLs

Extract org, project GUID, buildId, jobId from each failed check's URL: