Debug CI

Debug CI

Reproduce the selected failing Linux checks in an isolated checkout with the relevant CI toolchain. Follow AGENTS.md for the task branch, verification scope, test organization and result reuse. Keep the existing task branch and progress record when continuing a diagnosis.

Identify the failure and select the scope

gh pr checks <PR_NUMBER>
gh api repos/web-infra-dev/rslint/actions/runs/<RUN_ID>/jobs \
  --jq '.jobs[] | select(.conclusion == "failure") | {name, id}'
gh api repos/web-infra-dev/rslint/actions/jobs/<JOB_ID>/logs

Record the failing commit, job, runner architecture and failed test or check. Read .github/workflows/ci.yml and its referenced setup actions at the failing revision to reproduce the original failure. To validate the current fix, use the intended task revision plus its current changes and the CI configuration applicable to that target; record any environment differences from the failed run.

Trace the affected packages and consumers, then state the selected commands before running them. A failed CI job does not authorize all of that job's tests locally. If the user or reviewer explicitly requests a whole job or full suite, read its commands from the workflow at the selected revision rather than maintaining a second full-job script here. Windows and macOS failures need the corresponding platform; report that gap instead of claiming Docker parity.

Isolate the reproduction

Use a disposable independent clone outside the working checkout. This keeps its .git directory usable inside Docker and keeps Linux dependencies, Go binaries and VS Code downloads out of the user's current workspace.

git clone --no-hardlinks --no-checkout <repository-url-or-local-path> <repro-dir>

Before checkout, ensure the exact tested commit is present. A normal clone may omit PR merge/fork refs or unpublished local commits; fetch the corresponding CI/PR ref, or fetch from a local checkout that holds the commit. Verify the resolved SHA matches the recorded target: a current PR ref may have advanced since the failed run.

git -C <repro-dir> checkout --detach <tested-commit>

Read-only reproduction may stay detached. Before applying a patch or editing in the clone, select a task branch at the tested commit and verify git branch --show-current there, following AGENTS.md.

When validating an uncommitted fix, apply the intended staged and unstaged changes and copy any required untracked inputs into this clone before testing. A clone of HEAD alone does not contain the fix. Review the isolated diff against the intended input; exclude unrelated edits, host node_modules, generated binaries and caches.

If the patch changes a submodule gitlink, update the isolated clone's index too: for an initial combined patch against a clean checkout, use git apply --index <patch>. Plain git apply leaves the index unchanged, and git submodule update selects the indexed commit. Check that indexed gitlink against the intended revision and fetch the commit from the source submodule if it is not available remotely.

Initialize the compiler submodule when the selected checks need it, verify its HEAD matches the intended gitlink, then apply any intended changes inside that submodule:

git -C <repro-dir> submodule sync -- typescript-go
git -C <repro-dir> submodule update --init --depth 1

Ensure the chosen base ref and enough history for the lint merge-base exist in the isolated clone. A local clone's origin points to the source checkout, so verify the base commit rather than assuming its origin/main matches the source checkout's remote-tracking ref.

Reuse the same isolated clone, image and container while their relevant inputs remain unchanged. Install dependencies or rebuild outputs only when the selected execution path needs them and they are missing or stale. Do not delete the current workspace's node_modules or .vscode-test directories to obtain a clean Linux environment.

Match the Linux environment

Reuse a matching image if available. Otherwise prepare a temporary Docker build context outside the repository, using the selected revision's sources below. Install only the tools needed by the selected checks.

Pass the versions read from those sources as Docker build arguments, with no fallback version constants in the Dockerfile. For example, declare ARG GO_VERSION, ARG NODE_VERSION and ARG GOLANGCI_LINT_VERSION, use those arguments in the corresponding installations, and pass their resolved values when building. Keep the base image and installation architecture consistent with --platform; for Go downloads, Docker's TARGETARCH can select the archive architecture.

docker build --platform <ci-linux-platform> \
  --build-arg GO_VERSION=<selected-go-version> \
  --build-arg NODE_VERSION=<selected-node-version> \
  --build-arg GOLANGCI_LINT_VERSION=<selected-lint-version> \
  -t rslint-ci-test <temporary-build-context>

Omit unneeded tools and arguments, or add the selected Rust toolchain when the execution path builds the native parser. Do not copy fixed versions or the entire CI job into this skill. Record any runner services, image packages or architecture details that cannot be matched. On Apple Silicon, matching an x64 Linux runner may require emulation and increase runtime; do not treat an ARM run as equivalent evidence.