Validate branch readiness before push or PR using base-diff and local-change checks.
Run focused checks before push/PR.
Use bounded polling rather than agent-specific timeout fields.
For each command, set a max_wait_ms, poll every poll_interval_ms, and stop when the command completes or the max wait is reached.
If max_wait_ms is exceeded, report a timeout and continue to the next workflow step.
| Command type | max_wait_ms | poll_interval_ms |
|---|---|---|
git diff, git merge-base | 15000 | 1000 |
node scripts/check_changes.ts --ref "$BASE" | 180000 | 2000 |
node scripts/lint_ts_projects.js, yarn test:type_check --project | 120000 | 2000 |
node scripts/generate codeowners, node scripts/regenerate_moon_projects.js | 60000 | 2000 |
yarn test:jest (per package) | 300000 | 5000 |
Run these steps sequentially. Continue through all steps even if one fails. At the end, summarize issues that are likely to fail CI.
Collect changes relative to branch base, including untracked files. Detect the base branch rather than assuming main:
BASE=$(git merge-base HEAD main 2>/dev/null || git merge-base HEAD origin/main)
# Files changed since the branch base (committed + working tree changes).
git diff --name-only "$BASE"
# Untracked files.
git ls-files --others --exclude-standard
Combine and deduplicate results. From the changed file paths, identify:
kibana.jsonc and read its id field for the package ID.tsconfig.json files for those packages (sibling to kibana.jsonc).Prerequisite check: verify the TS project map exists by running a quick type check on one package. If it fails with TS Project map missing, stop and ask the user if they'd like you to run yarn kbn bootstrap. Once bootstrap completes (or if the user declines), proceed with the remaining steps.
check_changes against branch baseRun check_changes using the BASE computed in Step 0:
node scripts/check_changes.ts --ref "$BASE"
Record failures in the final summary, then continue with the remaining steps.
Validate and auto-fix tsconfig.json files across affected packages.
node scripts/lint_ts_projects.js --fix
This runs repo-wide but is fast. Note files modified by --fix and report any remaining errors.
Run type checking scoped to each affected package's tsconfig.json.
Only one --project flag per invocation — run separate commands for each package.
yarn test:type_check --project path/to/tsconfig.json
Also check downstream dependents — find packages whose kbn_references include any affected
package ID and type-check those too. This catches cross-package breakage that CI's full
tsc -b tsconfig.refs.json would find.
Use rg if available, otherwise fall back to grep:
# Preferred (rg).
rg -l '"@kbn/affected-package-id"' --glob 'tsconfig.json' .
# Fallback (grep).
grep -rl '"@kbn/affected-package-id"' --include='tsconfig.json' .
Deduplicate against already-checked packages. If a package has more than 20 downstream
tsconfigs, skip the downstream check and warn the user that a full tsc -b may be needed.
Run unit tests per affected package with coverage enabled.
yarn test:jest --coverage path/to/package/src/
If your environment provides a package-scoped unit-test tool, use the equivalent command.
After the run, read the coverage summary output and report overall line/branch/function coverage percentages per package. Flag any package whose line coverage is below 80% and provide recommendations to bring it above that threshold. Use specific uncovered files or line ranges when the coverage output provides them.
Regenerate the CODEOWNERS file from kibana.jsonc owner fields.
node scripts/generate codeowners
Check git diff .github/CODEOWNERS afterward — if the file changed, note it in the summary.
Regenerate moon project configs.
node scripts/regenerate_moon_projects.js --update
Check for unstaged changes afterward — if any moon configs changed, note them in the summary.
If the user asks to re-run branch-readiness checks after fixes, or if you make changes due to failures, run all steps again.
Report a summary including:
After reporting the summary, offer fixes by risk level:
--fix — offer to fix automatically when mechanical and low risk.Do not commit or stage automatically — let the user decide.