feat: add pipeline state rollup#146
Conversation
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? |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughAdds ChangesPipeline State Rollup
Sequence DiagramssequenceDiagram
participant Harness as Harness Files
participant Build as buildPipelineState
participant Write as writePipelineState
participant Lock as File Lock
participant Output as pipeline-state.json
Harness->>Build: manifest, tasks, metrics, events, approvals, evidence
Build->>Build: normalize and derive per-stage fields
Build->>Build: compute current stage/task and aggregates
Build-->>Write: structured state object
Write->>Lock: acquire advisory lock
Lock-->>Write: lock acquired
Write->>Output: writeJsonAtomic(state)
Output-->>Write: confirmed write
Write-->>Lock: release lock
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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/core/harness/pipeline-state.js`:
- Around line 159-160: The current stage detection in the find operation within
the code snippet only checks for events with a status field that matches
RUNNING_STATUSES, but it misses type-driven events like stage_started that don't
have a status field. Expand the condition in the find method to also check for
event types (such as checking if event.type equals stage_started or similar
running event types) in addition to the existing status check, so that events
without a status field can still be properly identified as running stages.
- Around line 235-237: The filter condition for the evidencePaths variable only
checks event.stage_id but legitimate events can use event.stage instead, causing
those events to be dropped from the evidence paths. Modify the filter logic in
the line that filters evidenceEvents to handle both event.stage_id and
event.stage properties when comparing against stage.id, ensuring all valid
evidence entries are included in the evidence-path derivation regardless of
whether they use stage or stage_id.
🪄 Autofix (Beta)
❌ Autofix failed (check again to retry)
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: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 58b26ceb-69f6-49e1-9079-c77a7d8fefbc
📒 Files selected for processing (3)
src/core/harness/pipeline-state.jssrc/index.jstests/pipeline-state.test.js
|
Note Autofix is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it. The branch was updated while autofix was in progress. Please try again. |
2 participants
Summary
Test Plan
Closes #113
Summary by CodeRabbit