Conversation
Wires releases into the analyzer end-to-end. After the existing PR/commit walk, the analyzer now: 1. Restores prior releases from the deployed site via the extended SiteFetcher (added in Phase A). 2. Fetches up to releasesCap (default 20) recent releases from GitHub via plain fetch() against the REST API — no new dependency. 3. For each release, calls compare(prev, this) to get the merge SHA list, matches against on-disk stories, builds a draft. 4. Computes inputsHash over (tag, sorted story IDs, stats). If an existing release file has the same hash, skips the LLM call entirely — idempotent across runs. 5. On hash miss, calls release-llm (lifted prompt + zod from gitsky's release-edition-generator.ts) to get quip + 2-3 paragraph release story, assembles the Release, writes it via writeRelease (with write-time schema validation from Phase A). 6. Rebuilds releases/manifest.json from final on-disk state. Configuration: - New workflow inputs releases-cap (default 20) and include-prereleases (default true) - Forwarded as GITPULSE_RELEASES_CAP and GITPULSE_INCLUDE_PRERELEASES - releasesCap=0 disables the releases pass entirely LLM call falls back to "Another one shipped." quip when the provider fails — analyzer never bails on a single release. Added: - github.ts: GitHubRelease type, fetchReleases() + fetchCompareShas() via plain fetch on the REST API - release-llm.ts: createReleaseEditor() with the lifted gitsky prompt and ReleaseEditionOutputSchema - release-builder.ts: pure functions matchStoriesForRelease, buildDraft, computeInputsHash, assembleRelease — all unit-tested - category-helpers.ts: primaryCategoryKey() shared helper - schemas.ts: ReleaseEditionOutputSchema (zod) + the .describe() text from gitsky's well-tuned tone constraints - index.ts: processReleases + processOneRelease orchestration Tests: 14 new release-builder cases (54 total in action workspace, was 40). Site untouched.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds a release-processing pipeline: new workflow inputs, REST GitHub release/compare support, release draft assembly and stable hashing, LLM-driven release edition generation with fallback, and orchestration to produce per-release JSON files and a final release manifest. ChangesRelease Processing Pipeline
Sequence DiagramsequenceDiagram
participant main as main()
participant gh as GitHub API
participant builder as Release Builder
participant llm as LLM
participant disk as Disk
main->>gh: fetchReleases(owner, repo, cap)
gh-->>main: [releases]
main->>main: filter/prune & sort releases
loop for each release (newest-first)
main->>gh: fetchCompareShas(base, head)
gh-->>main: [commit SHAs]
main->>builder: matchStoriesForRelease(stories, SHAs)
builder-->>main: matched stories
main->>builder: buildDraft(matched stories, release info)
builder-->>main: ReleaseDraft (with inputsHash)
main->>disk: read existing release.json?
alt inputsHash matches
main->>disk: rewrite as skipped
else inputsHash differs
main->>llm: generateEdition(release context)
alt LLM succeeds
llm-->>main: {quip, releaseStory}
else LLM fails
main->>main: getFallbackEdition()
end
main->>builder: assembleRelease(draft, edition)
main->>disk: write release.json
end
end
main->>disk: rebuild and write release manifest
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes 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)
Review rate limit: 9/10 reviews remaining, refill in 6 minutes. Comment |
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@action/src/index.ts`:
- Around line 162-174: The code fetches exactly cfg.releasesCap releases then
filters prereleases and pairs each release with sortedNewestFirst[i+1], which
can drop the predecessor for the oldest kept item; update the logic around
gh.fetchReleases and the handling of cfg.includePrereleases so you fetch enough
releases to preserve the predecessor window (e.g. request more than
cfg.releasesCap — at least cfg.releasesCap+1 — or loop fetching until you have
cfg.releasesCap non-prerelease items when cfg.includePrereleases is false),
apply the prerelease filter before trimming to the cap, and mirror the same fix
in the other block referenced by sortedNewestFirst pairing (the 195-205 area) to
ensure the oldest retained release still has a valid predecessor.
- Around line 149-159: After restoring prior releases (after
fetcher.restorePriorReleases and using priorReleaseManifest), prune stale
release JSON files in cfg.releasesDir before regenerating the manifest: remove
files for releases that no longer meet current filters (e.g.,
includePrereleases), exceed releasesCap, or no longer exist upstream; implement
this by listing JSON files under cfg.releasesDir, parsing their release
IDs/tags, comparing against the current fetched manifest and config
(includePrereleases, releasesCap), and deleting any mismatches (or adding a new
helper like pruneRestoredReleases(manifest, cfg) in the same module to
encapsulate the logic) so the subsequent manifest rebuild only includes valid,
current releases.
- Around line 274-286: When inputsHash matches, don't early-return; instead copy
existing.quip and existing.releaseStory onto the in-memory draft (e.g., set
draft.quip = existing.quip and draft.releaseStory = existing.releaseStory) so
you can skip the LLM call but still proceed to rewrite the JSON file from the
fresh draft and update disk metadata; keep the existing variables (existingPath,
existing, draft, inputsHash) and ensure the code path that triggers the LLM is
bypassed while the file-write logic still runs to persist the new JSON.
In `@action/src/release-builder.ts`:
- Around line 17-23: matchStoriesForRelease is currently returning any story
whose sha matches shaList, which lets direct-push commits (no PR) through and
later yields prNumber: 0 in toTopStory; change the filter to only include
stories that are associated with a PR (e.g., require s.prNumber > 0 or
s.pr?.number > 0) when computing wanted matches from allStories and shaList so
only PR-backed stories enter the release set; update the same logic for the
other occurrence referenced (lines 36-40) where release matching is performed.
🪄 Autofix (Beta)
✅ Autofix completed
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: ad062a27-e78d-4926-a072-1a73f7c73eef
📒 Files selected for processing (8)
.github/workflows/publish.yamlaction/src/category-helpers.tsaction/src/github.tsaction/src/index.tsaction/src/release-builder.test.tsaction/src/release-builder.tsaction/src/release-llm.tsaction/src/schemas.ts
|
Note Autofix is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it. Fixes Applied SuccessfullyFixed 2 file(s) based on 4 unresolved review comments. Files modified:
Commit: The changes have been pushed to the Time taken: |
Fixed 2 file(s) based on 4 unresolved review comments. Co-authored-by: CodeRabbit <noreply@coderabbit.ai>
Builds on Phase A (#5, merged). Wires releases end-to-end into the analyzer pipeline. No frontend changes yet — this PR produces the data; Phase C will render it.
What runs after the existing commit walk
Configuration
LLM failures fall back to `{quip: "Another one shipped.", releaseStory: ""}` — the analyzer never bails on one release.
Files
Tests
14 new release-builder cases — order independence of inputs hash, top-5 ranking, aggregate stats, first-release-no-predecessor, hash stability/divergence. 54 total action tests passing (was 40).
What's next
Test plan
Summary by CodeRabbit
New Features
Tests