chore: migrate to release-please with independent release lines#1539
Open
goldmedal wants to merge 6 commits intoCanner:mainfrom
Open
chore: migrate to release-please with independent release lines#1539goldmedal wants to merge 6 commits intoCanner:mainfrom
goldmedal wants to merge 6 commits intoCanner:mainfrom
Conversation
Replace manual release workflows (stable-release.yml, pypi-publish.yml, wren-pypi-publish.yml) with release-please-driven automation. Each component (ibis-server, mcp-server, wren-core-py, wren) now has its own release line with independent versioning, changelogs, and publish pipelines. - Add release-please config + manifest for 4 components - Create reusable publish workflows (Docker for ibis-server, PyPI for wren-core-py and wren, verify for mcp-server) - Add release-please.yml orchestration (push to main) - Add rc-release.yml for pre-release workflow with auto-increment - Make wren/pyproject.toml version static for release-please compatibility - Delete superseded manual release workflows Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
github-actions
bot
added
dependencies
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds Release Please-driven release automation with reusable publish workflows for ibis-server, mcp-server, wren-core-py, and wren; adds RC orchestration and release manifest/config; removes legacy stable-release and old wren PyPI workflows; pins Changes
Sequence Diagram(s)sequenceDiagram
participant RP as Release-Please Action
participant GH as GitHub Actions Controller
participant Repo as Repository (checkout / tag)
participant Publish as Publish Workflow (ibis/mcp/wren)
participant GHCR as GitHub Container Registry
participant PyPI as PyPI/TestPyPI
RP->>GH: on main push -> emit per-component outputs (release_created, version, tag_name)
GH->>Publish: conditional workflow_call(inputs: version, tag_name, pypi_target, prerelease)
Publish->>Repo: checkout at tag_name / read or inject version files
Publish->>GHCR: build per-arch images and push per-arch digests
Publish->>GHCR: create multi-arch manifest list from digests and push tags
Publish->>PyPI: build and publish Python distributions when applicable
Publish->>GH: upload artifacts and report status
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 6
🧹 Nitpick comments (1)
.github/workflows/rc-release.yml (1)
20-24: Scope permissions to least privilege per job.Current workflow-level permissions grant
packages: writeandid-token: writeto all jobs. Prefer minimal default permissions and elevate only where required.Proposed refactor
permissions: - contents: write - packages: write - id-token: write + contents: read jobs: create-rc: runs-on: ubuntu-latest + permissions: + contents: writeAlso applies to: 26-27
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/rc-release.yml around lines 20 - 24, Workflow-level permissions are too broad; change the top-level permissions block to the minimal default (e.g., set contents: read or remove workflow-level packages/id-token entries) and move elevated permissions to the specific job(s) that actually need them: grant packages: write only on the job that publishes packages and grant id-token: write only on the job that performs OIDC/auth. Update the permissions keys 'contents', 'packages', and 'id-token' accordingly so workflow-level permissions are least-privilege and per-job permissions provide the elevated rights where required.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/publish-ibis-server.yml:
- Around line 6-18: The workflow currently reuses the `version` input
(ibis-server release) as the MCP image version; change it so MCP_SERVER_VERSION
is not derived from `version`: add a new input (e.g., `mcp_version`) to the
workflow inputs and use that to populate MCP_SERVER_VERSION, or alternatively
check out the repository and read the version from `mcp-server/pyproject.toml`
(parse the version field) after checkout; update any references that set
MCP_SERVER_VERSION (instead of using `version`) to use the new `mcp_version`
input or the parsed pyproject value so ibis-server and mcp-server releases can
diverge.
In @.github/workflows/publish-wren-core-py.yml:
- Around line 14-18: The workflow's pypi_target input currently treats any value
other than "testpypi" as live PyPI; add explicit validation for the pypi_target
input (the input named pypi_target) and fail the workflow for any value not
equal to "pypi" or "testpypi." Implement this by adding an early validation
step/job (e.g., a small shell step in the publish job or a separate pre-check
job) that checks the pypi_target value and exits non‑zero with a clear error if
it is not exactly "pypi" or "testpypi"; update both occurrences referenced in
the workflow (the pypi_target input block and the publish logic used later) so
publishing cannot proceed with an invalid value.
- Around line 32-49: The Set version step uses non-portable sed -i calls to
rewrite version in wren-core-py/Cargo.toml and wren-core-py/pyproject.toml which
fail on macOS and Windows; replace the sed lines in the "Set version" step with
a cross-platform Python in-place edit (e.g., a short python -c one-liner or
script) that reads each file, replaces the version line pattern, and writes back
atomically, and apply the exact same replacement in the build-sdist job so both
jobs update Cargo.toml and pyproject.toml using the Python-based updater rather
than sed.
In @.github/workflows/publish-wren.yml:
- Around line 14-18: Add an explicit validation step for the workflow input
pypi_target that rejects any value not equal to "pypi" or "testpypi": create a
step (e.g., name: validate-pypi-target) that reads the pypi_target input
(inputs.pypi_target or github.event.inputs.pypi_target depending on invocation),
checks membership against the allowed set ["pypi","testpypi"], and exits with a
non-zero status and clear error message if the value is invalid so the publish
step never runs; then reference the validated value in the publish logic that
constructs the upload URL.
In @.github/workflows/rc-release.yml:
- Around line 25-27: The create-rc job races when computing rc.N and immediately
creating the tag; serialize runs per component by adding a concurrency/group
constraint scoped to each component so only one workflow run can
compute-and-create an RC for a given component at a time: update the create-rc
job to use GitHub Actions concurrency with a group key that includes the
component identifier (referencing the create-rc job and the steps that compute
rc.N and create the tag) so concurrent manual runs for the same component are
queued instead of racing.
- Around line 15-18: The workflow currently trusts the rc_version input as-is;
add explicit validation before any step that constructs the release/tag (the
rc_version input and the step that creates the release tag) by introducing an
early job/step that checks if rc_version is empty or matches a strict RC semver
regex (e.g. ^\d+\.\d+\.\d+-rc\.\d+$), and fail the run with a clear message when
it doesn't match; implement the check as a shell step that reads
inputs.rc_version (or env.RC_VERSION) and exits non-zero on invalid input so
downstream steps that create the tag/release never run with a malformed value.
---
Nitpick comments:
In @.github/workflows/rc-release.yml:
- Around line 20-24: Workflow-level permissions are too broad; change the
top-level permissions block to the minimal default (e.g., set contents: read or
remove workflow-level packages/id-token entries) and move elevated permissions
to the specific job(s) that actually need them: grant packages: write only on
the job that publishes packages and grant id-token: write only on the job that
performs OIDC/auth. Update the permissions keys 'contents', 'packages', and
'id-token' accordingly so workflow-level permissions are least-privilege and
per-job permissions provide the elevated rights where required.
🪄 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: b426fa1b-6ad2-43d8-91c7-853acfc95501
📒 Files selected for processing (11)
.github/workflows/publish-ibis-server.yml.github/workflows/publish-mcp-server.yml.github/workflows/publish-wren-core-py.yml.github/workflows/publish-wren.yml.github/workflows/rc-release.yml.github/workflows/release-please.yml.github/workflows/stable-release.yml.github/workflows/wren-pypi-publish.yml.release-please-manifest.jsonrelease-please-config.jsonwren/pyproject.toml
💤 Files with no reviewable changes (2)
- .github/workflows/wren-pypi-publish.yml
- .github/workflows/stable-release.yml
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
github-actions
bot
added
the
documentation
- Read MCP_SERVER_VERSION from mcp-server/pyproject.toml instead of reusing ibis-server version (versions will diverge) - Replace sed with Python for version patching (sed -i is not portable across macOS/Windows runners) - Validate rc_version format before creating tags - Add concurrency group to prevent RC tag race conditions Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (2)
RELEASING.md (2)
79-83: Add language specifier to code block.For better markdown best practices and syntax highlighting, add a language specifier to this fenced code block. Since this is a commit message example, you can use
textorcommit.📝 Proposed fix
-``` +```text feat(wren): prepare stable release Release-As: 1.0.0</details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against the current code and only fix it if needed.
In
@RELEASING.mdaround lines 79 - 83, Add a language specifier to the fenced
code block that contains the commit example ("feat(wren): prepare stable
release" and "Release-As: 1.0.0") by changing the opening fence fromtotext (orcommit) so the block becomestext and enables proper Markdown
syntax highlighting.</details> --- `97-101`: **Add language specifier to code block.** For better markdown best practices and syntax highlighting, add a language specifier to this fenced code block. Since this is a commit message example, you can use `text` or `commit`. <details> <summary>📝 Proposed fix</summary> ```diff -``` +```text feat(wren)!: redesign query engine BREAKING CHANGE: WrenEngine constructor signature changed ``` ``` </details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against the current code and only fix it if needed.
In
@RELEASING.mdaround lines 97 - 101, Update the fenced code block that
contains the commit example (the lines starting with "feat(wren)!: redesign
query engine" and "BREAKING CHANGE: WrenEngine constructor signature changed")
to include a language specifier (e.g., changetotext or ```commit) so
Markdown rendering and syntax highlighting work correctly; locate the code block
in RELEASING.md and prefix the opening backticks with the chosen specifier.</details> </blockquote></details> </blockquote></details> <details> <summary>🤖 Prompt for all review comments with AI agents</summary>Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In@RELEASING.md:
- Around line 79-83: Add a language specifier to the fenced code block that
contains the commit example ("feat(wren): prepare stable release" and
"Release-As: 1.0.0") by changing the opening fence fromtotext (or
commit) so the block becomestext and enables proper Markdown syntax
highlighting.- Around line 97-101: Update the fenced code block that contains the commit
example (the lines starting with "feat(wren)!: redesign query engine" and
"BREAKING CHANGE: WrenEngine constructor signature changed") to include a
language specifier (e.g., changetotext or ```commit) so Markdown
rendering and syntax highlighting work correctly; locate the code block in
RELEASING.md and prefix the opening backticks with the chosen specifier.</details> --- <details> <summary>ℹ️ Review info</summary> <details> <summary>⚙️ Run configuration</summary> **Configuration used**: defaults **Review profile**: CHILL **Plan**: Pro **Run ID**: `84105c67-4d99-488a-b0eb-d34afa567ead` </details> <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between f6d550beda9a25a0e50c3db2ed85a813620f1363 and 9103b728eaab2569b620ef10907a4c5c5744e3c9. </details> <details> <summary>📒 Files selected for processing (1)</summary> * `RELEASING.md` </details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (2)
.github/workflows/rc-release.yml (1)
53-59:⚠️ Potential issue | 🟠 MajorTighten
rc_versionvalidation to the manifest base version.Line 54 validates shape only. A wrong-base override (e.g., not matching
BASE_VERSION) still passes and can create unintended RC tags for the component.✅ Suggested fix
if [ -n "$RC_VERSION_INPUT" ]; then - if ! [[ "$RC_VERSION_INPUT" =~ ^[0-9]+\.[0-9]+\.[0-9]+-rc\.[1-9][0-9]*$ ]]; then - echo "::error::Invalid rc_version format: $RC_VERSION_INPUT (expected: X.Y.Z-rc.N)" + if ! [[ "$RC_VERSION_INPUT" =~ ^${BASE_VERSION}-rc\.[1-9][0-9]*$ ]]; then + echo "::error::Invalid rc_version: $RC_VERSION_INPUT (expected: ${BASE_VERSION}-rc.N)" exit 1 fi VERSION="$RC_VERSION_INPUT"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/rc-release.yml around lines 53 - 59, The current RC version check only enforces the shape of RC_VERSION_INPUT; update the validation to also ensure its base version matches BASE_VERSION by extracting the base X.Y.Z from RC_VERSION_INPUT (e.g., via regex capturing group) and comparing it to BASE_VERSION before assigning VERSION; if they differ, emit an error like "Invalid rc_version base: base (expected: $BASE_VERSION)" and exit 1. Use the existing variables RC_VERSION_INPUT and BASE_VERSION and keep the shape check (^[0-9]+\.[0-9]+\.[0-9]+-rc\.[1-9][0-9]*$) then derive the base portion and compare. Ensure VERSION is only set when both shape and base match..github/workflows/publish-wren-core-py.yml (1)
14-18:⚠️ Potential issue | 🟠 MajorFail closed on invalid
pypi_targetvalues.
pypi_targetis free-form, and Line 122 falls through to the live PyPI endpoint for any value other thantestpypi. This can publish to production on typos.🔒 Suggested fix
publish: name: Publish to ${{ inputs.pypi_target }} needs: [build-wheels, build-sdist] runs-on: ubuntu-latest @@ steps: + - name: Validate publish target + run: | + case "${{ inputs.pypi_target }}" in + pypi|testpypi) ;; + *) + echo "::error::pypi_target must be 'pypi' or 'testpypi'" + exit 1 + ;; + esac - name: Download all artifacts uses: actions/download-artifact@v4Also applies to: 109-110, 119-123
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/publish-wren-core-py.yml around lines 14 - 18, The workflow currently treats any pypi_target other than "testpypi" as live PyPI; change it to fail closed by validating pypi_target before selecting the repository: either restrict the input by replacing the free-form input with an options list containing only "pypi" and "testpypi" (input name: pypi_target) or add an explicit validation step that checks the pypi_target value (the conditional that currently compares to "testpypi") and exits with an error if the value is not exactly "pypi" or "testpypi"; only after validation set the repository URL for publishing.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In @.github/workflows/publish-wren-core-py.yml:
- Around line 14-18: The workflow currently treats any pypi_target other than
"testpypi" as live PyPI; change it to fail closed by validating pypi_target
before selecting the repository: either restrict the input by replacing the
free-form input with an options list containing only "pypi" and "testpypi"
(input name: pypi_target) or add an explicit validation step that checks the
pypi_target value (the conditional that currently compares to "testpypi") and
exits with an error if the value is not exactly "pypi" or "testpypi"; only after
validation set the repository URL for publishing.
In @.github/workflows/rc-release.yml:
- Around line 53-59: The current RC version check only enforces the shape of
RC_VERSION_INPUT; update the validation to also ensure its base version matches
BASE_VERSION by extracting the base X.Y.Z from RC_VERSION_INPUT (e.g., via regex
capturing group) and comparing it to BASE_VERSION before assigning VERSION; if
they differ, emit an error like "Invalid rc_version base: base (expected:
$BASE_VERSION)" and exit 1. Use the existing variables RC_VERSION_INPUT and
BASE_VERSION and keep the shape check (^[0-9]+\.[0-9]+\.[0-9]+-rc\.[1-9][0-9]*$)
then derive the base portion and compare. Ensure VERSION is only set when both
shape and base match.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 8be48a37-505c-4409-906b-1bea6a636350
📒 Files selected for processing (4)
.github/workflows/publish-ibis-server.yml.github/workflows/publish-wren-core-py.yml.github/workflows/publish-wren.yml.github/workflows/rc-release.yml
✅ Files skipped from review due to trivial changes (1)
- .github/workflows/publish-wren.yml
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Contributor
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 @.github/workflows/rc-release.yml:
- Around line 89-95: Move the "Create GitHub pre-release" step (the
softprops/action-gh-release invocation using tag_name: ${{
steps.rc.outputs.tag_name }}, name: "${{ inputs.component }} ${{
steps.rc.outputs.version }}", prerelease: true, generate_release_notes: true)
out of its current location and into a final job that runs after the chosen
publish job(s) succeed; make that job depend_on the publish job(s) (the selected
PyPI or Docker publisher) so the prerelease is only created when the downstream
publication step completes successfully, and ensure the final job's conditional
matches the publish path selected so the prerelease isn't created for failed or
skipped publishers.
- Around line 36-38: Add a branch-guard step to the workflow so RCs can only be
cut from main: before the tagging/“create RC” step, check the dispatched ref
(github.ref or workflow_dispatch input) and fail early unless it equals
refs/heads/main; ensure this check runs after the actions/checkout@v4 step (or
replace its ref usage) so the action cannot proceed to create tags from a
non-main branch. Reference the workflow_dispatch trigger and the
actions/checkout@v4 usage when adding the new “Ensure main branch” step.
- Around line 53-55: The regex is loose because BASE_VERSION (e.g., 0.25.0) is
interpolated unescaped; replace the single regex check with a two-step
validation: first verify the prefix using a string comparison like [[
"$RC_VERSION_INPUT" == "$BASE_VERSION"-rc.* ]] (or use parameter expansion to
check startswith), then validate only the numeric suffix by stripping the prefix
(e.g., suffix=${RC_VERSION_INPUT#"$BASE_VERSION"-rc.}) and checking suffix
against the numeric regex ^[1-9][0-9]*$; update the check around
RC_VERSION_INPUT/BASE_VERSION accordingly and keep the existing error message
when validation fails.
- Around line 20-23: Change the workflow-level permissions to minimize blast
radius: set the top-level permissions mapping to only "contents: read" instead
of "contents: write / packages: write / id-token: write", and move the stronger
permissions ("contents: write" and any needed "packages: write" or "id-token:
write") into the specific job that needs them (the create-rc job). Update the
create-rc job's permissions block to explicitly grant "contents: write" (and any
other minimal rights it requires) so other jobs keep their current,
tightly-scoped permissions.
🪄 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: 8b475e30-4dd6-4b77-8438-8d6b0253f096
📒 Files selected for processing (1)
.github/workflows/rc-release.yml
- Scope permissions: workflow-level contents:read, elevate only in jobs that need write (create-rc, create-release) - Guard against non-main dispatch (ref: main + GITHUB_REF check) - Fix rc_version validation: use string prefix match instead of regex (dots in BASE_VERSION matched any char) - Move GitHub pre-release creation to final job that runs only after publish succeeds Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/rc-release.yml:
- Around line 142-143: The current job "if:" condition gates pre-release
creation only against 'failure' but not cancelled runs; update the condition on
the job (the if: expression referencing needs and needs.*.result) to also reject
any 'cancelled' results—e.g., add a check like !contains(needs.*.result,
'cancelled') alongside the existing !contains(..., 'failure') so pre-release
creation only proceeds when all dependent jobs succeeded (and none were
cancelled).
🪄 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: fbaa27d2-9406-47ef-b37b-b3508cbee8d4
📒 Files selected for processing (1)
.github/workflows/rc-release.yml
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
stable-release.yml,pypi-publish.yml,wren-pypi-publish.yml) with release-please-driven automation<component>-v<version>-rc.NtagsFiles
release-please-config.json.release-please-manifest.json.github/workflows/release-please.yml.github/workflows/rc-release.yml.github/workflows/publish-ibis-server.yml.github/workflows/publish-wren-core-py.yml.github/workflows/publish-wren.yml.github/workflows/publish-mcp-server.ymlwren/pyproject.tomlstable-release.ymlpypi-publish.ymlwren-pypi-publish.ymlTest plan
feat(wren): ...commit → verify release-please creates a Release PR for wren onlywren-v0.3.0+ PyPI publishbuild-image.ymlcontinues working for SHA-tagged continuous builds🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Chores
Documentation
Style