feat: tag-triggered release workflow for wheel, sdist and Windows bundle - #159
Conversation
|
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:
📝 WalkthroughWalkthroughThe release workflow supports manual builds while publishing only on tag pushes, validates exactly three expected release assets, and documents version matching. Windows packaging now installs ChangesRelease automation
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant Trigger
participant ReleaseWorkflow
participant AssetVerification
participant GitHubRelease
Trigger->>ReleaseWorkflow: Push v* tag or manually dispatch workflow
ReleaseWorkflow->>ReleaseWorkflow: Build Python and Windows artifacts
ReleaseWorkflow->>AssetVerification: Verify exactly three expected assets
AssetVerification->>GitHubRelease: Publish assets for tag push
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 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 @.github/workflows/release.yml:
- Line 3: Update the release documentation to describe tags without implying
annotation requirements: in .github/workflows/release.yml lines 3-3 and 12-12,
replace “annotated version tag” and “annotated test tag” with “version tag” and
“test tag”; in README.md line 268, replace “annotated tag” with “tag”.
- Around line 20-21: Change the workflow-level permissions to grant contents:
read by default, then add job-level contents: write permissions only to the
publish job. Ensure the build jobs retain read access and do not inherit write
access.
🪄 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: a6671609-70f2-4c47-9aab-56b31585baca
📒 Files selected for processing (3)
.github/workflows/release.ymlREADME.mdcursor-browser.spec
There was a problem hiding this comment.
[Should fix] Issue #155 acceptance criteria and Verification section ask for a fork tag push or dry run with the resulting artifact names and sizes recorded in the PR body.
The workflow header (release.yml:7–10) and README table document expected names and local 0.2.0 wheel/sdist sizes, but this PR body only has local sanity-check commands - no fork Actions run link or actual uploaded asset sizes (especially CursorChatBrowser-windows.zip).
Please add a short "Release workflow verification" section here with either:
- a fork tag push (e.g. v0.0.0-test) + link to the Actions run and the three asset filenames/sizes from the Release, or
- a dry-run summary from a local
python -m build+pyinstallerrun including the Windows zip size at the locked dependency tree.
Without that, we won't know the publish job works end-to-end before is-10.
[Nice to have] .github/workflows/tests.yml:123
cursor-browser.spec now lists webview as a hiddenimport (see spec line 20), and the release workflow correctly installs pywebview before PyInstaller. The unittest matrix Windows PyInstaller steps (123–129) still build without pywebview, so CI only smoke-tests --help and does not exercise the same bundle graph as the published Release asset.
Consider adding python -m pip install 'pywebview>=5.0,<7' to the Windows 3.12 PyInstaller block (matching release.yml:68–74) so CI validates the desktop bundle we actually ship.
Added a dry-run table above with local wheel, sdist, and Windows zip sizes from the locked tree. Windows 3.12 PyInstaller step now installs pywebview>=5.0,<7 before the build, same as release.yml. |
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 @.github/workflows/release.yml:
- Around line 122-130: The “Verify release asset set” step must validate
artifact filenames against the intended release version, not only extensions and
counts. Derive the release version from the workflow’s existing tag/version
symbol, then assert the single .whl and .tar.gz names contain that version while
preserving the existing three-file and Windows ZIP checks.
- Line 105: Update the release publish condition to require both github.ref_type
== 'tag' and github.event_name == 'push', keeping manually dispatched tag runs
build-only. In the asset validation step, verify the expected
cppa_cursor_browser-<version>-py3-none-any.whl and
cppa_cursor_browser-<version>.tar.gz filenames in addition to the existing wheel
and sdist count checks.
🪄 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: ef89cd26-b892-4c4d-91fe-0d097023c75f
📒 Files selected for processing (4)
.github/workflows/release.yml.github/workflows/tests.ymlREADME.mdcursor-browser.spec
🚧 Files skipped from review as they are similar to previous changes (2)
- cursor-browser.spec
- README.md
wpak-ai
left a comment
wpak-ai
left a comment
There was a problem hiding this comment.
-
.github/workflows/release.yml:80-81,.github/workflows/tests.yml:136-138: replace both--helpsmoke tests with an assertion that the pywebview payload actually landed, e.g. fail whendist\CursorChatBrowser\_internal\webview\libis absent, and add an explicitshell: pwshto the release step (the step gating the Windows binary cannot fail for two independent reasons,launcher.py:24exits on--helpbeforeimport webviewat line 27 while PyInstaller logs an unresolved hidden import and exits 0, andconsole=Falseatcursor-browser.spec:58makes the exe GUI-subsystem so the defaultpwshnever waits or sets$LASTEXITCODE, so this PR's own fix has no test that can observe it and a windowless exe would publish silently) -
.github/workflows/release.yml:11: replace thev0.0.0-testfork rehearsal withv0.2.0, which matches pyproject today and exercises the full path including publish (the documented recipe can never produce a Release, because the verify step derives the expected wheel name from the tag while hatchling names it from pyproject's0.2.0, andVersion("0.0.0-test")raisesInvalidVersionso retagging pyproject to match is impossible, this is the recipe for issue #155's Part E acceptance criterion) -
pyproject.toml,.github/workflows/release.yml:123,README.md:268,CHANGELOG.md:113: add a preflight step at the top ofbuild-pythoncomparing${GITHUB_REF_NAME#v}against[project].versionand failing with a message naming both values (the tag-equals-pyproject invariant is instructed in the README, stored in pyproject, mirrored by the CHANGELOG headings and compare links, and enforced only by a baretest -fin the final job, so editing one surface without the others costs both builds and surfaces as an unexplained non-zero exit) -
.github/workflows/release.yml:72,.github/workflows/tests.yml:126,pyproject.toml:29: add a check that the pywebview range in both workflows matches[project.optional-dependencies].desktop, since installing the extra directly would bypassrequirements-lock.txtand is not a clean substitute (pywebview>=5.0,<7is written out three times character-identically and the comment attests.yml:123asserts the copies match, but nothing enforces it, so a bump in pyproject would silently leave the shipped Windows bundle built against the old range)
Pushed fixes for all four. That last bit had to move out of tests.yml because the inline guard was matching its own file and failing CI. |
3 participants
Closes #155
Adds a release workflow that runs when you push a version tag. It builds the Python packages and the Windows zip, checks that all three files are there, then attaches them to the GitHub Release. You can also trigger the build jobs manually without publishing. CI now installs pywebview for the Windows PyInstaller step so it matches what the release job ships.
I dry-ran the build locally on 0.2.0: wheel about 154 KiB, sdist about 225 KiB, Windows zip about 36 MiB. The exe passed a --help smoke test. A test tag on a fork is still the way to confirm publish end-to-end before we cut 0.2.1.
Summary by CodeRabbit
New Features
v*tag pushes.Bug Fixes
Documentation
pyproject.tomlversion with the pushed tag, and updated related wording.