feat: installer error-report generation (schema v1)#2
Conversation
|
Claude finished @forkni's task in 5m 15s —— View job Code review — PR #2 (
|
The multi-agent code-review plugin exhausted 60 turns on PR #2 (feat/installer-error-report, a stacked diff with no CLAUDE.md to shortcut convention discovery) before posting a verdict. Bumping headroom rather than trusting a partial/incomplete review.
The multi-agent code-review plugin exhausted 60 turns on PR #2 (feat/installer-error-report, a stacked diff with no CLAUDE.md to shortcut convention discovery) before posting a verdict. Bumping headroom rather than trusting a partial/incomplete review.
|
Re-triggering review with bumped max-turns (60 -> 120) — prior run exhausted its turn budget mid-review. |
Summary
sd_installer/report.py: builds a self-contained diagnostic report (schema v1) on installation phase failure, with an env-var allowlist/denylist so secrets never leak into the reportsd_installer/installer.py: trackcurrent_phase/_last_pip_stderr, add_write_install_error_report(), wrap the phase-calling loop in try/finally so a failure always writes a report before re-raisingsd_installer/cli.py: add areportsubcommandThis is PR I-2, chained on
deps/cuda-link-1.12-torch-modelopt-onnx(PR I-1, #1) because_write_install_error_report()readscurrent_phasevalues set byphase4b_cuda_link/phase4c_cuda_link_env, which only exist on that branch, not onmain. Once PR I-1 merges, this PR's base should be retargeted tomain.Test plan
python -m sd_installer reportwrites aninstall_error_report_*.txtCLAUDE_CODE_OAUTH_TOKENsecret on this fork)