GitHub CI Triage
Use this page after a PR push starts GitHub Actions or when a reviewer asks for CI failure details.
What This Covers
Section titled “What This Covers”This is a developer workflow for inspecting existing GitHub Actions runs from a local terminal. It does not replace local verification, PR readiness, or canonical feature tests.
Inspect Current Runs
Section titled “Inspect Current Runs”List recent runs for the branch:
gh run list -R nethopper2/ai --branch <branch-name> --limit 10For this repo, the branch name is usually the current feature branch:
git branch --show-currentWhen a run fails, pull only failed-step logs first:
gh run view <run-id> -R nethopper2/ai --log-failedFor longer failures, save the log and search it:
gh run view <run-id> -R nethopper2/ai --log-failed > /tmp/<run-id>.logrg -n "FAIL|Failed|Error|AssertionError|Unhandled|exit code|Process completed" /tmp/<run-id>.logIf gh cannot fetch logs, open the Actions run in GitHub and copy the failed job section. The GitHub CLI can have platform limits when associating jobs with logs.
What To Share
Section titled “What To Share”When sharing a CI failure with another developer or coding assistant, include:
- workflow name and run id
- failed job name
- failed command or step name
- first concrete assertion, stack trace, or setup error
- whether checkout/install/test steps ran
Do not share secrets, raw env values, tokens, database URLs, OAuth credentials, or private connector data from logs.
How To Decide The Next Check
Section titled “How To Decide The Next Check”| CI signal | Usual next step |
|---|---|
| Test assertion or type/build error | Reproduce the smallest local command that exercises the same package or file. |
| Workflow syntax/setup error | Fix the workflow or setup script, then rely on GitHub to validate the CI-only path. |
| Docker registry or external-service timeout | Add bounded retry or a clearer setup failure if the workflow owns that boundary. |
| Failure before checkout | Treat it as runner/service initialization, not repo code. |
| Failure only after formatting/import order changes | Do not rerun expensive local suites solely for formatting. Check formatting and syntax instead. |
Current PR Gates
Section titled “Current PR Gates”The PR regression workflow currently splits repo, integration, chat, and browser E2E checks into separate jobs. Production build checks are separate workflows. A failure in one job does not stop unrelated workflows from starting, but branch protection may require specific checks to be green before merge.
Automatic PR workflows must not run PR-controlled checkout/install/build/test code on configurable, self-hosted, or larger-runner labels, and PR jobs must not receive provider or deployment secrets. The executable local guard is:
bun run guard:github-actions-policyThe web large-runner production build workflow is manual-dispatch only. Provider-secret chat answer-quality evals skip pull_request and run from trusted dev pushes, weekday schedules, or reviewed manual dispatches.
Canonical Sources
Section titled “Canonical Sources”.github/workflows/pr-regression-tests.yml.github/workflows/production-builds.yml.github/workflows/production-build-web-large.yml.github/workflows/production-build-token-replacer.yml.github/workflows/chat-orchestration-evals.ymlscripts/checkGithubActionsWorkflowPolicy.tsscripts/runPrTests.tsscripts/runRepoTests.tspackage.jsonREADME_TESTS.mdapps/support-dev/src/content/docs/workflows/verification.mdapps/support-dev/src/content/docs/workflows/pr-readiness.md