[FEATURE] Split release changelog by project (lexical-graph | byokg | both) - #521
Conversation
|
BYOKG-RAG Coverage Report: The coverage is at 94.71% (target: 80%). Download the HTML report here. |
|
Lexical Graph Coverage Report: The coverage is at 65.77% (target: 80%). Download the HTML report here. |
mykola-pereyma
left a comment
mykola-pereyma
left a comment
There was a problem hiding this comment.
LGTM — nice, well-tested per-project changelog tooling, and thanks for resolving the RELEASE.md TODOs. No shell-injection concerns (git via subprocess list form; the ref passed as a quoted env var rather than a ${{ }} expansion), least-privilege on the new test workflow, and strong unit coverage of the classifier.
One non-blocking thing worth a follow-up: the changelog append isn't idempotent.
softprops/action-gh-release with append_body: true appends RELEASE_CHANGELOG.md to the release body on every execution. These workflows run on release: [released|prereleased] events, which can be re-run from the Actions UI (or a released event can follow a prereleased one for the same release on the lexical-graph workflow). Each execution would append another copy of the generated changelog to the same release notes, so a retried/re-published release ends up with duplicated changelog blocks.
A couple of ways to make it safe under re-runs:
- Have the step compute the full release body (author notes + a single delimited changelog section) and set the body via the API rather than appending, replacing any prior auto-generated block (e.g. delimit with an HTML-comment marker like
<!-- auto-changelog:start -->…<!-- auto-changelog:end -->and regenerate between the markers); or - Guard the append so it only runs once per release (skip if the marker is already present in the release body).
Not blocking — approving as-is — but worth hardening before this is relied on for a release that gets re-run.
(Also minor, for later: previous_release_tag is the one logic-heavy piece without a unit test since it needs git — a small git-backed test over a temp repo with a couple of tags, including a .dev one, would lock in the baseline-selection behavior.)
|
Lexical Graph Coverage Report: The coverage is at 65.82% (target: 80%). Download the HTML report here. |
|
BYOKG-RAG Coverage Report: The coverage is at 94.71% (target: 80%). Download the HTML report here. |
1 similar comment
|
BYOKG-RAG Coverage Report: The coverage is at 94.71% (target: 80%). Download the HTML report here. |
noel-improv
left a comment
noel-improv
left a comment
There was a problem hiding this comment.
The changes for the path-based change-log generator looks cleanly implemented and workflows look decent just a few questions I added below the main ones revolve tag names.
|
Lexical Graph Coverage Report: The coverage is at 65.95% (target: 80%). Download the HTML report here. |
|
BYOKG-RAG Coverage Report: The coverage is at 94.71% (target: 80%). Download the HTML report here. |
noel-improv
left a comment
noel-improv
left a comment
There was a problem hiding this comment.
looks good, just one non-blocking comment raised
|
BYOKG-RAG Coverage Report: The coverage is at 94.71% (target: 80%). Download the HTML report here. |
|
Lexical Graph Coverage Report: The coverage is at 65.95% (target: 80%). Download the HTML report here. |
3 participants
Description
Add a path-based changelog generator that classifies each commit by the project folders it touched, so per-project releases no longer list the other project's changes.
Changes
release_message.shnow delegates to the generator for local previews (release_message.sh lexical-graph|byokg|both)Problem
Related issue (if any): #
Testing
pytest)Checklist
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.