Triage a CUBRID PR's CI failure

Decide what to do about a red PR: re-run it, update its base, or dig in. Built for submodule bump PRs on CUBRID/cubrid, but it works on any PR of that repo. Analysis only: it never re-runs CI, never comments on the PR, and never pushes.

Step 0: How CUBRID's CI is laid out (why this skill works the way it does)

A PR's tests report from one of two systems; the script reads whichever one the PR's checks name.

GitHub Actions' other checks (code-style, cppcheck, license, pr-style, the TC Merge Gate, ...) are lint, style, or merge gates, not test results.

gha-ci details that change the answer:

• A comment-started run's own headSha is the develop tip, not the PR head. The tested SHA is in the gate job's resolved: line, which the script reads.
• /run rerun <run-id> re-runs that run's failures (plus TCs changed since) and reuses the build of the same SHA, so it cannot clear a failure caused by a stale base. Only a base update (a new SHA, a new build) followed by /run all can.
• The nightly runs each develop commit once, so a case that fails only now and then can pass there and look 고유. For a case develop does not explain (it passes at the base, or develop has no verdict), the script reads other PRs' failed runs of the last 3 days, at most 40, newest first, and stops once every such case has turned up. A run that failed more than 3 of the suite's shards is left out: that PR broke something, which says nothing about flakiness. A case newer develop passes is not looked up, because PRs on older bases fail it too: that is a stale base, not flakiness.
• The failure diff exists only in the collect job's step summary (the API does not expose it) and in each shard's JUnit XML on the internal artifact server http://192.168.1.48:30080. For 고유 cases the script tries that server; when it is unreachable, it prints the link, and the diff is on the run page's Summary.

Re-running anything needs a token (CircleCI) or a PR comment (gha-ci), which is why this skill only reports.

Step 1: Run it

python3 ${CLAUDE_SKILL_DIR}/assets/ci_check.py [PR]
python3 ${CLAUDE_SKILL_DIR}/assets/ci_check.py https://github.com/CUBRID/cubrid/actions/runs/<run-id>

PR is a number or URL; with no argument it uses the current branch's PR. Pass a gha-ci run URL instead when the user names a run, or when a later push or base update left the failing run off the PR head: the PR's checks show only the current head's statuses. Needs gh (authenticated), curl, and python3.

A green PR costs nothing: the script prints the check summary and stops, so this is also the right command for a plain "is CI ok?" question. Test results are downloaded only when a test job actually failed. A gha-ci triage reads a few runs' logs (an sql shard's out of its run's log zip, which gh caches; any other job's on its own) and takes about half a minute. Reading other PRs' runs, done only for a case still 고유 or 판정 불가 after develop, adds up to about a minute.

If neither system has reported on the PR head, the script says so: a gha-ci PR needs a /run all comment.

Step 2: Read the classification

For each failing test job or suite the script prints:

A gha-ci 공통 line also shows what newer develop does. (base 4f1a68c 실패 · develop 5cd1de8 통과) means the PR's base fails the case and develop has since fixed it: a stale base. The 판단 then names the develop commit whose issue key matches the TC path (cbrd_27381 → [CBRD-27381]), when there is one.

Step 3: Decide

Do not report a verdict the data does not support. On CircleCI, when the comparison sample turns up nothing for a test, the script counts it as 고유; say that it is unproven rather than asserting the bump broke it. On gha-ci, a develop pass is inferred only when the case was in that run's testcases (a TC added after the base's nightly snapshot never ran there), so such a case is 판정 불가, not 고유. When newer develop passes it, the honest answer is "update the base and /run all to find out"; when develop says nothing (a feature/* base, which the nightly does not test), a same-build /run rerun <run-id> at least shows whether it is flaky. A gha-ci flaky 추정 is a strong hint, not proof: another PR can fail the same case for its own reason (a change in the same area, or an older base that lacks a fix). Call it settled only when the script marks it 확정.

Step 4: Hand off

Report the classification and the recommendation. To act, the user does it: re-running a CircleCI job needs a token, a gha-ci re-run is a PR comment (/run all, /run rerun <run-id>), and updating the base means pushing. Show the relevant link (the script prints each failed check's URL) so they can act from there.

If the base needs updating on a bump PR, point the user to /submodule-bump --status (a manual-only skill), which shows whether an open bump PR already covers the submodule head.