Repository navigation
ci: ship an actual binary, replacing the release that never released - #151
Conversation
Every job in release.yml was gated, directly or transitively, on a `check-python-pkg` step testing for `python/Cargo.toml`. That check has reported `exists=false` for the whole life of the workflow, so `build-wheels`, `build-sdist`, `publish-pypi` and `github-release` were skipped on every run -- while the workflow reported success. Both tags cut so far shipped nothing: `gh release view` reports an empty `assets` array for v0.1.0 and for v0.2.0. Two releases, zero artifacts, green checks. Replaced with a workflow that builds the CLI for five targets and attaches them to the release. There is no Python package to publish any more, so the PyPI path and its `id-token: write` permission are deleted rather than repaired. Targets are built on native runners -- ubuntu-latest, ubuntu-24.04-arm, macos-15-intel, macos-latest, windows-latest -- so no `cross` toolchain or linker configuration is involved. This repository is public, so the ARM and Intel-macOS runners are free. Two design points worth stating: `workflow_dispatch` builds every target and stops; only a `v*` tag also publishes. A release workflow whose sole trigger is a tag is one whose first real test is a release you cannot take back. The dispatch path makes it exercisable. The binary name is read from `cargo metadata` rather than hardcoded, so this survives the wh -> writ rename (#145) with no edit. Confirmed against both trees: metadata yields `wh` on main and `writ` on the rename branch. Also: `--locked` so a release builds from the committed Cargo.lock, `if-no-files-found: error` and `fail_on_unmatched_files: true` so a silently empty release fails loudly this time, and a single SHA256SUMS generated on one runner rather than per-target (macOS has `shasum`, Linux has `sha256sum`). Verified locally, running the workflow's own package step verbatim: `cargo build --release --locked` succeeds; the archive contains the binary plus README and LICENSE; sha256sum produces a valid digest; and the packaged binary runs (reports `wh 0.2.0`). actionlint is clean -- it caught the retired `macos-13` label during authoring, which is a fair advertisement for #149. Closes #41 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016yFLnKN9zQA7uzgpYxTrjX
🤖 CodeAnt AI — Review Status
|
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
|
Warning Review limit reachedNext included review available in 42 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Team Run ID: 📒 Files selected for processing (1)
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 |
codeant-ai
Bot
added
the
size:L
![codescene-access[bot]](https://avatars.githubusercontent.com/in/3755875?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
![amazon-q-developer[bot]](https://avatars.githubusercontent.com/in/1220912?s=60&v=4){kind=small}
There was a problem hiding this comment.
This PR successfully fixes the broken release workflow that was silently skipping all jobs. The replacement Rust binary release workflow is well-structured with good error handling and testability via workflow_dispatch.
Critical Issues Found:
- Missing
jqon Windows runners will cause builds to fail - Missing error handling for README.md/LICENSE files could cause silent failures
Both issues have actionable fixes provided. Once addressed, this workflow should successfully ship binary releases for all five target platforms.
You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.
| staging="${bin}-${TARGET}" | ||
| mkdir -p "dist/${staging}" | ||
| cp "target/release/${bin}${ext}" "dist/${staging}/" | ||
| cp README.md LICENSE "dist/${staging}/" |
There was a problem hiding this comment.
Add error handling for missing README.md or LICENSE files. The cp command will fail if these files don't exist, causing the workflow to fail silently without a clear error message.
| cp README.md LICENSE "dist/${staging}/" | |
| if [ ! -f README.md ] || [ ! -f LICENSE ]; then | |
| echo "::error::README.md or LICENSE not found" | |
| exit 1 | |
| fi | |
| cp README.md LICENSE "dist/${staging}/" |
| - name: Build | ||
| run: cargo build --release --locked | ||
|
|
||
| # The binary name is read from cargo metadata rather than hardcoded, so |
There was a problem hiding this comment.
🛑 Dependency Missing: The packaging script relies on jq to parse cargo metadata, but jq is not installed by default on GitHub's windows-latest runner. This will cause the Windows build to fail.
| # The binary name is read from cargo metadata rather than hardcoded, so | |
| # jq is required for parsing cargo metadata in the Package step below | |
| - name: Install jq | |
| if: runner.os == 'Windows' | |
| run: choco install jq -y | |
| # The binary name is read from cargo metadata rather than hardcoded, so |
Up to standards ✅🟢 Issues
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Addresses both Amazon Q review comments on this PR. Accepted: an explicit check for README.md and LICENSE before packaging. `set -euo pipefail` already aborted the step if either were missing, so the failure was never silent -- but it surfaced as `cp: cannot stat ...` buried in the log. Naming the two files a rename could plausibly break makes the failure explain itself on the run summary. Rejected, with evidence: the claim that `jq` is not installed on windows-latest and would fail the Windows build. `jq` is preinstalled on all three GitHub runner images, and this step is `shell: bash`, so one script runs everywhere. This was verified rather than assumed before the comment was filed -- dispatching this workflow on the branch built x86_64-pc-windows-msvc successfully and produced a 679,896-byte artifact, alongside the other four targets. Adding `choco install jq` would install a second copy of a tool already on PATH and add ~30s to every Windows release build. The reasoning is recorded in the workflow itself rather than only in a review thread, so the next reader does not re-litigate it. actionlint clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016yFLnKN9zQA7uzgpYxTrjX
There was a problem hiding this comment.
No application code in the PR — skipped Code Health checks.
See analysis details in CodeScene
Quality Gate Profile: Pay Down Tech Debt
Install CodeScene MCP: safeguard and uplift AI-generated code. Catch issues early with our IDE extension and CLI tool.
Amazon Q — both findings already handled in the file, rejecting
|
github-project-automation
Bot
moved this from Backlog
to Done
in Autonomous Software Engineering
2 participants
User description
The defect
Every job in
release.ymlwas gated, directly or transitively, on acheck-python-pkgstep testing forpython/Cargo.toml. That check has reportedexists=falsefor the whole life of the workflow, sobuild-wheels,build-sdist,publish-pypiandgithub-releasewere skipped on every run — while the workflow itself reported success.Both tags cut so far shipped nothing:
Two releases, zero artifacts, green checks.
There is no Python package to publish any more, so the PyPI path and its
id-token: writepermission are deleted rather than repaired.What ships now
The CLI, built for five targets on native runners — no
crosstoolchain or linker configuration involved. This repository is public, so the ARM and Intel-macOS runners are free.ubuntu-latestx86_64-unknown-linux-gnuubuntu-24.04-armaarch64-unknown-linux-gnumacos-15-intelx86_64-apple-darwinmacos-latestaarch64-apple-darwinwindows-latestx86_64-pc-windows-msvcTwo design points worth calling out
workflow_dispatchbuilds every target and stops; only av*tag also publishes. A release workflow whose sole trigger is a tag is one whose first real test is a release you cannot take back. The dispatch path makes it exercisable — and is how I would suggest smoke-testing this before the next tag.The binary name is read from
cargo metadata, not hardcoded, so this survives thewh->writrename in #145 with no edit. Confirmed against both trees:Failing loudly this time
--locked— a release builds from the committedCargo.lock, never a lockfile silently updated on the runnerif-no-files-found: errorandfail_on_unmatched_files: true— a silently empty release now fails instead of reporting greenSHA256SUMSgenerated on a single runner rather than per-target (macOS hasshasum, Linux hassha256sum)Verification
I ran the workflow's own package step verbatim against this workspace:
actionlintis clean. It caught the retiredmacos-13runner label while I was writing this — a fair advertisement for #149.Honest limit: the tag-triggered
releasejob cannot be fully exercised without pushing a tag. Thebuildmatrix — which is where all the real work is — runs onworkflow_dispatchand is fully testable now.Closes #41
🤖 Generated with Claude Code
https://claude.ai/code/session_016yFLnKN9zQA7uzgpYxTrjX
CodeAnt-AI Description
Ship usable multi-platform CLI binaries from every release
What Changed
Impact
✅ Downloadable CLI binaries for five operating systems and architectures✅ Test releases before creating a version tag✅ Verifiable release archives with SHA256 checksums💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.
Summary by cubic
Fixes the release workflow so releases actually ship a binary; previously every job was gated on a Python package check that always failed, leaving both
v0.1.0andv0.2.0with zero artifacts and green checks..tar.gzarchives plus aSHA256SUMSfile onv*tag pushes.workflow_dispatchruns the full build matrix but stops before publishing, so the workflow can be exercised without cutting a release.id-token: writepermission; there is no Python package anymore.--locked,if-no-files-found: error,fail_on_unmatched_files: true, and explicit checks thatREADME.mdandLICENSEexist before packaging.cargo metadata, so the upcomingwh→writrename needs no workflow edit.Written for commit 16414c7. Summary will update on new commits.