feat(compress): 빌드 요약·디렉토리 리스팅 요약·중복 제거 규칙 추가 - #56
Conversation
이슈 #21 표의 규칙 기반 결과 압축에서 누락됐던 3개 규칙을 구현하고 skipDirListing 데드코드를 제거. - 빌드 진행 로그 → [Build succeeded] 또는 [Build failed: 에러만] 요약 - 디렉토리 리스팅(ls -l 3+ 줄) → [dir listing: N entries] 요약 - 연속 중복 라인 제거 (consecutive dedup) - skipDirListing 플래그(dead code) 제거 — 작성되었으나 한 번도 읽히지 않음 회귀: bare word 한 줄이 디렉토리 리스팅으로 오탐지되지 않도록 plain-ls 매칭을 total 헤더로 좁힘. 테스트: 87개 통과 (기존 80 + 신규 7). 빌드·tsc 통과.
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
|
Warning Review limit reached
Next review available in: 9 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthrough
Changes트레이토리 결과 압축
Estimated code review effort: 3 (Moderate) | ~20 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 239ba79dc0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const summary = buildFailed | ||
| ? `[Build failed]\n${buildErrors.join("\n")}` | ||
| : "[Build succeeded]"; |
There was a problem hiding this comment.
When build output contains progress lines but fails with only the standard shell marker, e.g. [exit: 1], this summary still reports [Build succeeded] because buildFailed is only set from ERROR_LINE matches while exit markers are merely kept later. That gives the model contradictory and misleading compressed history for failed build commands that don't print an error-looking line, so non-zero [exit: N] should also drive the failed summary.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
수정 완료 — non-zero [exit: N] 감지 추가. buildProgressSeen 상태면 buildFailed=true로 설정하고 마커는 그대로 보존. df7637a
| } else if (dirRun > 0) { | ||
| // Too few to be a listing — keep them. | ||
| for (let k = 0; k < dirRun; k++) kept.push("__kept_dir__"); | ||
| } |
There was a problem hiding this comment.
For one or two ls -l-style lines, this path intends to keep them because they are below the directory-listing threshold, but it stores only __kept_dir__; the dedupe pass then drops that sentinel, so outputs like ls -l README.md or a two-file listing disappear entirely instead of being preserved. Store the original pending lines or flush them before replacing longer runs with a summary.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
수정 완료 — __kept_dir__ 센티넬 제거. 짧은 dir run(1-2줄)은 dirPending 버퍼에 원본을 저장 후 그대로 보존. df7637a
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/trajectory.ts`:
- Around line 197-198: Update the BUILD_PROGRESS_LINE handling in the trajectory
parsing flow so progress lines are skipped only when they do not match
ERROR_LINE. Preserve error lines for the later build-error collection branch,
matching the existing BUILD_DONE_LINE guard behavior and ensuring buildFailed is
set for lines such as “webpack compiled with 1 error.”
- Line 199: Update BUILD_DONE_LINE and the related build-output handling in the
surrounding completion and error-collection branches so failure terminal lines
such as “Build failed” are recognized as build completion markers and are not
appended to buildErrors. Preserve actual diagnostic errors when the build fails,
and strengthen the existing “preserves only errors when a build fails” assertion
to verify the terminal failure line is not duplicated.
- Around line 254-265: Update the directory-listing aggregation around dirRun so
short runs preserve their original lines instead of pushing "__kept_dir__";
track those lines in a dirRunLines collection and reuse it in both the normal
flush and trailing flush paths. Exclude LS_TOTAL_LINE header matches from the
listing count so the summarized entry total reflects only actual items. Remove
the obsolete "__kept_dir__" filtering from the dedup stage.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 679b227f-7ff5-48b9-a9d2-6e4a0dcb38db
📒 Files selected for processing (2)
src/trajectory.tstest/compress-result.test.ts
CodeRabbit·Codex 리뷰 반영: 1. BUILD_PROGRESS_LINE에 ERROR_LINE 가드 추가 — "webpack compiled with 1 error" 같은 라인이 progress로 소비되어 [Build succeeded]로 오탐지되던 문제 수정. 2. BUILD_DONE_LINE에 fail(ed) 매칭 추가 — "Build failed" 종료 라인이 buildErrors에 중복 수집되던 문제 수정 (요약 헤더와 본문 중복 제거). 3. non-zero [exit: N] 감지 — 에러 라인 없이 실패한 빌드도 [Build failed] 처리. 4. 짧은 dir run(1-2줄) 보존 — __kept_dir__ 센티넬이 dedup 패스에서 소실되어 ls -l README.md 결과가 날아가던 문제 수정. 원본을 pending 버퍼로 보존. 테스트: 91개 통과 (신규 4개 회귀 테스트 포함). 빌드·tsc 통과.
CodeRabbit 추가 지적 반영 — `total 24` 헤더가 dirRun에 포함되어 [dir listing: N entries]의 N이 실제 항목 수보다 1 많았던 문제. 헤더는 listing 감지 트리거로 유지하되 카운트에서 제외. 테스트: 92개 통과 (total 헤더 카운트 회귀 테스트 추가). tsc 통과.
1 participant
변경 요약
이슈 #21 표의 규칙 기반 결과 압축에서 누락됐던 3개 규칙을 구현하고,
skipDirListing데드코드를 제거.이전까지 구현된 규칙(통과 테스트 요약,
__pycache__/.git제거, 에러/traceback 유지, git status/diff 보존)에 더해:[Build succeeded]또는[Build failed: 에러만]요약skipDirListingdead code)[dir listing: N entries]요약근본 원인 (데드코드)
compressResult의skipDirListing플래그가true로 세팅은 되었으나 한 번도 읽히지 않는 데드코드였음 — 디렉토리 리스팅 처리가 작성되다 만 상태. 이번에 리스팅 감지 + 요약을 완성하고 플래그를 제거.회귀 방지
초안에서 bare word 한 줄(
result-a)이 plain-ls리스팅으로 오탐지되어 trajectory-retention 테스트가 실패함. plain-ls매칭을total헤더로 좁히고, bare word 오탐 방지 테스트를 추가.테스트
npm run build통과tsc --noEmit타입체크 통과Closes #21
Summary by CodeRabbit
개선 사항
테스트