#104:CHANGELOG + deprecation policy (stability signaling).#108
#104:CHANGELOG + deprecation policy (stability signaling).#108AuraMindNest wants to merge 3 commits into
Conversation
ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThis PR initializes a Keep-a-Changelog ChangesRelease Notes Automation
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
There was a problem hiding this comment.
🧹 Nitpick comments (2)
CHANGELOG.md (1)
14-14: ⚡ Quick winConsider adding guidance for future maintainers on [Unreleased] population.
The
[Unreleased]section is a placeholder for ongoing development. To help future maintainers, consider adding a brief comment or example showing the expected structure (e.g.,### Added,### Changed,### Deprecated,### Removed).💡 Example guidance section
## [Unreleased] ### Added <!-- - New feature description --> ### Changed <!-- - Behavior change description --> ### Deprecated <!-- - Deprecation notice with removal version --> ### Removed <!-- - Removed feature from previous deprecation --> ### Fixed <!-- - Bug fix description -->This template helps maintainers and CI reviewers immediately see what changelog categories to populate when a new release is prepared.
🤖 Prompt for 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. In `@CHANGELOG.md` at line 14, Add a short maintainer guidance comment under the "[Unreleased]" header describing the expected changelog structure and include the canonical section headings (e.g., "### Added", "### Changed", "### Deprecated", "### Removed", "### Fixed") as a template/example so future contributors know how to populate the section; place this guidance directly beneath the existing "## [Unreleased]" line in CHANGELOG.md and keep it concise and commented or clearly delimited so it can be removed when releasing..github/workflows/release.yml (1)
71-99: ⚡ Quick winVerify changelog extraction regex handles [Unreleased] vs. dated versions correctly.
The regex pattern
rf"^## \[{re.escape(version)}\].*?(?=^## |\Z)"will match the first header matching the version, regardless of whether it's## [1.0.0] - 2026-06-11or## [Unreleased]. In normal operation, the workflow is manually triggered and the operator should ensure they're releasing a dated version (not the Unreleased placeholder).To explicitly guard against accidentally releasing [Unreleased] notes:
- Add a pre-check that the extracted section contains a date (or is not [Unreleased])
- Or, update the regex to require a date:
rf"^## \[{re.escape(version)}\]\s+- \d{4}-\d{2}-\d{2}"Consider which approach fits your release discipline.
🔍 Proposed regex update (requires date in header)
- pattern = rf"^## \[{re.escape(version)}\].*?(?=^## |\Z)" + # Require date in format "## [X.Y.Z] - YYYY-MM-DD" to avoid extracting [Unreleased] + pattern = rf"^## \[{re.escape(version)}\]\s+-\s+\d{{4}}-\d{{2}}-\d{{2}}.*?(?=^## |\Z)"Alternatively, add a post-check after extraction:
section = match.group(0).rstrip() +if "[Unreleased]" in section[:50]: + raise SystemExit(f"Extracted section looks like [Unreleased]; aborting release") notes_file = Path(os.environ["RUNNER_TEMP"]) / "release-notes.md"🤖 Prompt for 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. In @.github/workflows/release.yml around lines 71 - 99, The changelog extraction can accidentally pick the [Unreleased] section; update the logic around the pattern/match/section extraction to guard against that by either making pattern require a date (modify the pattern variable to something like requiring "\s+- YYYY-MM-DD" after the header) or add a post-check after section = match.group(0) that inspects the header (e.g., check the first ~50 chars of section for "[Unreleased]") and raise SystemExit with a clear message if found; ensure the check uses the existing version/env variables and still writes notes_file only when the section is a dated release.
🤖 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.
Nitpick comments:
In @.github/workflows/release.yml:
- Around line 71-99: The changelog extraction can accidentally pick the
[Unreleased] section; update the logic around the pattern/match/section
extraction to guard against that by either making pattern require a date (modify
the pattern variable to something like requiring "\s+- YYYY-MM-DD" after the
header) or add a post-check after section = match.group(0) that inspects the
header (e.g., check the first ~50 chars of section for "[Unreleased]") and raise
SystemExit with a clear message if found; ensure the check uses the existing
version/env variables and still writes notes_file only when the section is a
dated release.
In `@CHANGELOG.md`:
- Line 14: Add a short maintainer guidance comment under the "[Unreleased]"
header describing the expected changelog structure and include the canonical
section headings (e.g., "### Added", "### Changed", "### Deprecated", "###
Removed", "### Fixed") as a template/example so future contributors know how to
populate the section; place this guidance directly beneath the existing "##
[Unreleased]" line in CHANGELOG.md and keep it concise and commented or clearly
delimited so it can be removed when releasing.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 31bcadd3-54aa-424a-9080-637584b52217
📒 Files selected for processing (3)
.github/workflows/release.ymlCHANGELOG.mdREADME.md
henry0816191
left a comment
There was a problem hiding this comment.
Fix line 389("4. Creates a GitHub Release with auto-generated notes, ...") of docs/deployment-runbook.md as extracting the version info from changelog.md
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 @.github/workflows/release.yml:
- Around line 93-99: The release workflow is vulnerable because
steps.versions.outputs.tag and weblate_version are interpolated into shell
commands without validation; update the "Parse versions from pyproject.toml"
step to validate project.version against a semantic version regex (e.g.,
/^\d+\.\d+\.\d+$/) and fail early if it doesn't match, then export only the
validated values (e.g., validated_tag, validated_weblate_version) for use by the
"Create and push tag" and "Create GitHub Release" steps instead of raw
steps.versions.outputs values; ensure the git tag and release steps consume
those validated environment variables so shell metacharacters cannot be
injected.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: b79abbde-9fac-4243-b1d7-db71f7079f7c
📒 Files selected for processing (3)
.github/workflows/release.ymldocs/deployment-runbook.mdpyproject.toml
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's internal server error or limits when posting large numbers of comments. If you are seeing this consistently it is likely a permissions issue. Please check "Moderation" -> "Code review limits" under your organization settings.
Actionable comments posted: 1
🤖 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 @.github/workflows/release.yml:
- Around line 93-99: The release workflow is vulnerable because
steps.versions.outputs.tag and weblate_version are interpolated into shell
commands without validation; update the "Parse versions from pyproject.toml"
step to validate project.version against a semantic version regex (e.g.,
/^\d+\.\d+\.\d+$/) and fail early if it doesn't match, then export only the
validated values (e.g., validated_tag, validated_weblate_version) for use by the
"Create and push tag" and "Create GitHub Release" steps instead of raw
steps.versions.outputs values; ensure the git tag and release steps consume
those validated environment variables so shell metacharacters cannot be
injected.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: b79abbde-9fac-4243-b1d7-db71f7079f7c
📒 Files selected for processing (3)
.github/workflows/release.ymldocs/deployment-runbook.mdpyproject.toml
🛑 Comments failed to post (1)
.github/workflows/release.yml (1)
93-99:
⚠️ Potential issue | 🟠 Major | ⚖️ Poor tradeoffTemplate injection in
.github/workflows/release.ymlat lines 93-99 and 101-110.Both the "Create and push tag" step (L93-99) and "Create GitHub Release" step (L101-110) interpolate version strings from
steps.versions.outputsdirectly into shell commands without validation. Ifpyproject.tomlonmainwere compromised to include shell metacharacters inproject.version, those would execute. The shared root cause is missing input validation in the "Parse versions from pyproject.toml" step. Add semantic version format validation (e.g.,\d+\.\d+\.\d+) after parsingproject.versionto reject malformed input before it reaches shell expansion sites, or consistently use environment variables to reduce injection surface.🧰 Tools
🪛 zizmor (1.25.2)
[info] 96-96: code injection via template expansion (template-injection): may expand into attacker-controllable code
(template-injection)
[info] 97-97: code injection via template expansion (template-injection): may expand into attacker-controllable code
(template-injection)
🤖 Prompt for 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. In @.github/workflows/release.yml around lines 93 - 99, The release workflow is vulnerable because steps.versions.outputs.tag and weblate_version are interpolated into shell commands without validation; update the "Parse versions from pyproject.toml" step to validate project.version against a semantic version regex (e.g., /^\d+\.\d+\.\d+$/) and fail early if it doesn't match, then export only the validated values (e.g., validated_tag, validated_weblate_version) for use by the "Create and push tag" and "Create GitHub Release" steps instead of raw steps.versions.outputs values; ensure the git tag and release steps consume those validated environment variables so shell metacharacters cannot be injected.Source: Linters/SAST tools
Close #104.
Summary by CodeRabbit