Repository navigation
Release v0.1.10 - #120
Merged
Merged
Release v0.1.10#120
Conversation
First release that ships Windows x86_64 binaries.
- packages/cli/package.json + package.json: 0.1.9 → 0.1.10 (the
version embedded in the Bun-compiled binaries; root bumped for
consistency).
- CHANGELOG.md: new [0.1.10] section describing the Windows
additions that landed in PR #119 (Windows binary + runtime
tarball cross-compiled from Linux, smoke-windows CI gate).
What this release adds that v0.1.9 didn't:
- finalrun-windows-x64.exe attached to the GitHub Release.
- finalrun-runtime-0.1.10-windows-x64.tar.gz attached to the
GitHub Release (Android-only, no iOS bundles — the existing
isDarwin gate in buildRuntimeTarball.mjs handles that).
- smoke-windows job in release.yml that runs `finalrun --version`
and `--help` on a real windows-latest runner before tagging.
Validates the cross-compiled .exe actually executes.
Known gaps (deliberate, follow-up PRs):
- No install.ps1 yet. Windows users install by manually downloading
finalrun-windows-x64.exe from the release page and adding it to
PATH. The release notes (auto-assembled from the template) tell
them this.
- finalrun upgrade fails on Windows because upgradeCommand.ts
shells out to `bash -c "curl … | bash"`. Windows users re-
download from the release page until install.ps1 ships.
- install.sh still rejects Windows hosts. Windows is supported via
the standalone .exe, not via the bash installer.
- No code signing — Windows users will see SmartScreen on first run.
After this PR merges:
Actions tab → Release → Run workflow → branch=main → Run
trigger publishes finalrun v0.1.10 with all 20 release artifacts
(5 binaries + 5 runtime tarballs + 10 .sha256 sidecars).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 42 minutes and 39 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis release (0.1.10) introduces Windows x86_64 support with a new PowerShell-based installer script. The upgrade command is updated to dispatch platform-specifically: PowerShell on Windows with Changes
Sequence DiagramsequenceDiagram
participant CLI as CLI User
participant Upgrade as upgradeCommand
participant Shell as Shell (bash/PowerShell)
participant GitHub as GitHub API
participant Filesystem as Filesystem
CLI->>Upgrade: Run upgrade (--ci flag)
Upgrade->>Upgrade: Detect platform (win32 vs other)
alt Windows Platform
Upgrade->>Shell: Invoke PowerShell with install.ps1<br/>FINALRUN_NON_INTERACTIVE=1
Shell->>GitHub: HEAD request to latest release
GitHub-->>Shell: Redirect to release tag
Shell->>GitHub: Download finalrun.exe + runtime.tar.gz
GitHub-->>Shell: Binary + tarball
Shell->>Filesystem: Unblock file, move to bin/, extract runtime
Filesystem-->>Shell: File operations complete
Shell-->>CLI: Install summary (binary-only)
else Non-Windows Platform
Upgrade->>Shell: bash -c "curl ... | bash -- --ci"
Shell->>GitHub: Fetch install.sh
GitHub-->>Shell: Install script
Shell->>GitHub: Download binary
GitHub-->>Shell: Binary
Shell->>Filesystem: Install to path
Filesystem-->>Shell: Complete
Shell-->>CLI: Install summary
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 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 |
Lifts Windows out of "manual download" and into one-liner install parity with macOS/Linux: irm https://raw.githubusercontent.com/final-run/finalrun-agent/main/scripts/install.ps1 | iex scripts/install.ps1 mirrors install.sh structurally, with the Windows-shaped divergences from earlier design discussion baked in: - TLS 1.2 set explicitly as line 1 of executable code. PS 5.1 defaults to TLS 1.0/1.1, which GitHub rejects with a cryptic "underlying connection was closed" error otherwise. - Architecture check: AMD64 only. Rejects ARM64 with a specific message ("Bun does not currently provide a bun-windows-arm64 cross-compile target") so a future Surface user knows it's a build-side limitation, not a CLI runtime gap. - PATH wiring via [Environment]::SetEnvironmentVariable User scope, not rc-file munging. Idempotent split-and-contains check. - Net.WebClient.DownloadFile for the binary, not Invoke-WebRequest (PS 5.1's IWR buffers ~120MB into memory and is much slower). - Unblock-File post-download to strip the NTFS Zone.Identifier ADS so users skip the "this file came from another computer" prompt. - tar.exe for runtime tarball extraction (Windows 10 1803+). - Single Y/n Android prompt — no 1/2/3 menu, no iOS option. iOS local execution requires xcodebuild (macOS-only); the prompt text points users at `finalrun cloud` for iOS testing instead. - scrcpy install: winget → Chocolatey → manual instructions. - HttpWebRequest (not Invoke-WebRequest) for the version-redirect follow because the response-uri property name differs between PS 5.1 and PS 7. upgradeCommand.ts gains a process.platform === 'win32' branch that spawns powershell.exe -NoProfile -NoLogo -Command "irm <url> | iex" instead of `bash -c "curl <url> | bash"`. The --ci flag travels via FINALRUN_NON_INTERACTIVE env var on Windows because PowerShell's irm|iex can't forward args to the in-memory script (no equivalent of bash's `-s --`). install.ps1 already honors that env var, the same way install.sh does. Public install commands ride along on the existing release-notes-template.md, which is auto-included on every GitHub Release page. The template now has separate macOS/Linux and Windows sections; the previous "PowerShell installer is in the works" line is gone. Note: the workspace dist (packages/cli/dist) is regenerated from source in CI, so the upgradeCommand.ts change reaches end users via the v0.1.10 binary (which incorporates this commit). The .ps1 file is hosted from main on raw.githubusercontent.com — install.ps1 URLs in the binary will work as soon as this lands on main. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
![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 the current code and only fix it if needed.
Inline comments:
In `@scripts/install.ps1`:
- Around line 142-160: The idempotency check in Update-UserPath uses a
case-sensitive membership test ($segments -contains $BinDir) which causes
duplicate PATH entries on Windows; change the check to use a case-insensitive
comparison (e.g., use -icontains or compare upper/lower-cased values) so
$segments reliably matches $BinDir regardless of casing, and ensure the rest of
the function (trimming and SetEnvironmentVariable) remains unchanged.
- Around line 106-140: Install-Binary fails on Windows because Move-Item -Force
cannot replace a running finalrun.exe; change the replace logic in
Install-Binary to a stash-then-replace pattern: after downloading to $tmpPath
and Unblock-File, attempt Move-Item; if it throws a sharing violation, rename
the existing $binPath to a unique stash name (e.g., "$binPath.old.{Get-Date
-Format yyyyMMddHHmmss}" or include the process ID), then Move-Item $tmpPath to
$binPath; finally attempt to remove the stashed file asynchronously (or
Remove-Item with -ErrorAction SilentlyContinue) so the running process can
continue and the new binary is installed. Ensure references to $binPath,
$tmpPath and the Install-Binary function are updated and error cases still exit
with code 1.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: b6ac5fcd-908a-48db-86ba-b8a77b88e0b2
📒 Files selected for processing (6)
.github/release-notes-template.mdCHANGELOG.mdpackage.jsonpackages/cli/package.jsonpackages/cli/src/upgradeCommand.tsscripts/install.ps1
1. (Critical) Move-Item over a running finalrun.exe fails on Windows. Windows holds an exclusive image-section lock on the live .exe, so `Move-Item -Force $tmpPath $binPath` would fail with a sharing violation any time `finalrun upgrade` ran (which spawns powershell to run this script while the parent finalrun.exe is still loaded). Fresh installs were unaffected because there was no existing finalrun.exe to lock. Fix: stash the existing binary as finalrun.exe.old via Rename-Item first, then Move-Item the new binary into place. Renaming a running .exe IS allowed — it only updates the directory entry, not the open image. The stash file becomes deletable on the next upgrade once the parent process has exited; subsequent installs clean it up. 2. (Minor) Update-UserPath idempotency check was case-sensitive. `$segments -contains $BinDir` does an ordinal comparison, but Windows paths are case-insensitive. A user whose existing PATH already contained `C:\Users\foo\.finalrun\Bin` (any other casing) would get a duplicate appended on every install, eventually growing the user PATH unbounded. Fix: switch to `-icontains` for case-insensitive comparison. Both fixes from CodeRabbit comments on PR #120: - r3144242527 (exe locking) - r3144242530 (path casing) Cannot validate locally without a Windows host. Will surface in post-release manual testing or follow-up `finalrun upgrade` runs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
5 tasks
zikani03
pushed a commit
to golang-malawi/finalrun-agent
that referenced
this pull request
May 29, 2026
The install section was carrying details that belong elsewhere:
- "Downloads a self-contained finalrun binary into ~/.finalrun/bin/,
adds it to your PATH, downloads the per-platform runtime tarball,
prompts for Android/iOS, installs host tools..." — internals of
install.sh, already documented in the script's header comment and
in the auto-generated release notes (.github/release-notes-template.md).
- "For CI / non-interactive environments..." — CI flag and env-var
documentation, already in release notes and install.sh's --help.
- "After install, run finalrun doctor..." — diagnostic guidance that
fits better in finalrun --help / docs/troubleshooting.md.
A README install block should answer "how do I get this on my machine"
in one or two commands, not document the installer's behavior. Trimmed
to just the install one-liners per platform plus a single sentence on
the iOS-on-Windows constraint (preempts the most common support
question without expanding the section).
Adds Windows install instructions for the first time. Until v0.1.10,
the .ps1 installer didn't exist; v0.1.10 shipped it (commit 9d5b78e on
PR droid-ash#120) and the .exe / runtime tarball are now on every release. The
README continues to point only at install.sh and ignores Windows —
this catches it up.
Net: 14 lines → 6 lines, +1 platform.
Co-Authored-By: Claude Opus 4.7 (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
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
First release that ships Windows x86_64 binaries.
packages/cli/package.json+ rootpackage.jsonfrom 0.1.9 → 0.1.10[Unreleased]Windows entries into[0.1.10]so the release workflow can extract them as the GitHub Release notesWhat v0.1.10 adds that v0.1.9 didn't
finalrun-windows-x64.exeattached to the GitHub Releasefinalrun-runtime-0.1.10-windows-x64.tar.gzattached (Android-only — iOS local execution requires macOS)smoke-windowsCI job that runs the cross-compiled.exeon a realwindows-latestrunner before the release job tags or publishes (proven on PR #119 — first dry-run loggedfinalrun --versionand--helpexit 0 on Windows Server 2022)Total artifacts on the Release page: 20 files (5 binaries + 5 tarballs + 10
.sha256sidecars), up from 16 in v0.1.9.Known gaps (intentional — follow-ups)
install.ps1yet. Windows users install by downloading the.exefrom the release page and adding it to PATH. The auto-generated release notes spell this out.finalrun upgradefails on Windows (upgradeCommand.ts:60-66 shells out tobash -c "curl … | bash"). Windows users re-download from the release page untilinstall.ps1ships.install.shcontinues to reject Windows hosts. Windows is supported via the standalone.exe, not via the bash installer.Trigger sequence after merge
Workflow expected to take ~2-3 minutes:
build(~1m30s) — cross-compile 5 binaries + 5 tarballs onubuntu-24.04smoke-windows(~30s) — runfinalrun.exe --version/--helponwindows-latestrelease— tagv0.1.10at the build SHA, create the GitHub Release with all 20 artifacts, mark as--latestIf any step fails the tag is never created, no public release ships, and we fix forward.
Verify after release
Expected: 20 downloadable assets including
finalrun-windows-x64.exeandfinalrun-runtime-0.1.10-windows-x64.tar.gz, release body with install instructions and the[0.1.10]CHANGELOG section.Test plan
gh workflow run release.yml -f branch=mainbuild,smoke-windows, andreleasejobs all greenfinalrun-windows-x64.exeand run on a Windows box to validate end-to-end🤖 Generated with Claude Code
Summary by CodeRabbit
Release Notes
New Features
Documentation