Skip to content

feat: install.ps1 - #60

Merged
khvn26 merged 2 commits into
mainfrom
install-ps1
Jul 30, 2026
Merged

feat: install.ps1#60
khvn26 merged 2 commits into
mainfrom
install-ps1

Conversation

@khvn26

@khvn26 khvn26 commented Jul 29, 2026

Copy link
Copy Markdown
Member

Follow-up to #59, for Windows.

Mirrors install.sh: pinned version bumped by release-please, sha256 from checksums.txt, installs to ~\.local\bin, edits PATH unless told not to, and every parameter is also readable from the FLAGSMITH_* environment variables.

Two Windows-specific wrinkles:

  • PATH goes through HKCU\Environment as ExpandString, because [Environment]::SetEnvironmentVariable rewrites REG_EXPAND_SZ as REG_SZ and would break any %VAR% already in PATH. Then a dummy user-scope write broadcasts WM_SETTINGCHANGE so open shells reread it. Pattern from pixi via bun; uv does the same.
  • iex cannot pass arguments — the PowerShell twin of FLAGSMITH_CLI_VERSION=… curl … | sh. Hence param() plus env fallbacks, so irm | iex, the scriptblock form and a saved file all work.

Add-CiPath appends the install dir to $GITHUB_PATH, so the step after an install finds flagsmith on PATH. The release smoke job depends on that.

Verified

  • the archive layout it assumes: Windows zips are flagsmith_<version>_windows_{amd64,arm64}.zip containing flagsmith.exe, both in checksums.txt
  • the x-release-please-version line rewrites correctly under the updater's real regex
  • pre-commit passes; shellcheck and shfmt correctly ignore .ps1

Verification status

windows-latest CI runs PSScriptAnalyzer (clean) and ./install.ps1 -DryRun, so the script parses and its argument, architecture and URL handling execute on a real Windows host. It has never done a full install anywhere — the release smoke job is the first time that happens.

Written on a machine with no PowerShell, so CI is doing all the work here.

@coderabbitai

coderabbitai Bot commented Jul 29, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@khvn26, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 41 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 6595170e-6157-48aa-b211-09a4915180fe

📥 Commits

Reviewing files that changed from the base of the PR and between 9e65a63 and 3ce1542.

📒 Files selected for processing (5)
  • .github/workflows/pull-request.yml
  • .github/workflows/release.yml
  • README.md
  • install.ps1
  • release-please-config.json

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@khvn26 khvn26 changed the title feat: add install.ps1 feat: install.ps1 Jul 29, 2026
@khvn26
khvn26 marked this pull request as ready for review July 30, 2026 09:30
@Zaimwa9

Zaimwa9 commented Jul 30, 2026

Copy link
Copy Markdown

@themis-blindfold review

Comment thread install.ps1 Outdated
@themis-blindfold

Copy link
Copy Markdown
Contributor

⚖️ Themis review: 🧹 Ship it, nits inside

Clean, well-structured PowerShell installer that faithfully mirrors install.sh with appropriate Windows-specific adaptations — registry-based PATH (REG_EXPAND_SZ preservation via direct registry writes), WM_SETTINGCHANGE broadcast through the dummy-var trick, TLS 1.2 enforcement for PS 5.1, and $GITHUB_PATH integration. Architecture detection with the RuntimeInformation → registry fallback covers PS 5.1 on both x64 and ARM64. CI is thorough: PSScriptAnalyzer + DryRun on every PR, real install from release artifacts on tag push.

Area Score
🎯 Correctness 5/5
🧪 Test coverage 4/5
📐 Code quality 5/5
🚀 Product impact 4/5

🧹 Nits

  • install.ps1:108FLAGSMITH_NO_MODIFY_PATH treats any non-empty value (including "0") as truthy; install.sh checks != 1, so the same env var means different things across the two scripts.
📝 Walkthrough
  • install.ps1 — new PowerShell installer: download, SHA-256 verify, extract, PATH via registry, $GITHUB_PATH for Actions.
  • CI (pull-request.yml) — adds PSScriptAnalyzer lint + -DryRun smoke on windows-latest.
  • CI (release.yml) — adds release-time install smoke test on windows-latest, mirroring the existing install.sh matrix.
  • README.md — adds the Windows one-liner (irm | iex).
  • release-please-config.json — registers install.ps1 for x-release-please-version bumps.
🧪 How to verify
  1. On a Windows host (or Actions runner), run ./install.ps1 -DryRun and confirm it prints the expected version, arch, and URLs.
  2. Run a full install with -Version <known-tag> and verify flagsmith --version succeeds.
  3. Set $env:FLAGSMITH_NO_MODIFY_PATH = "1" before install; confirm ~\.local\bin is NOT added to the user PATH registry key.
  4. On a GitHub Actions windows-latest runner, confirm the release smoke job passes and flagsmith --version works in the step after install.

Automate: the existing release workflow's install-script-windows job covers (2) and (4).

Product take: Windows goes from "grab the .zip manually" to a proper irm | iex one-liner with checksum verification and PATH setup — a meaningful install-experience improvement that puts Windows on par with Unix.

🧭 Assumptions & unverified claims
  • The .DESCRIPTION references https://get.flagsmith.com/install.ps1 as the canonical URL; this review assumes that redirect is or will be set up separately.
  • The x-release-please-version marker is assumed to rewrite correctly based on parity with the working install.sh marker and the PR author's verification.

PowerShell without a PowerShell machine — that's commitment to CI-driven development. · reviewed at 16ee32e

Zaimwa9
Zaimwa9 previously approved these changes Jul 30, 2026

@Zaimwa9 Zaimwa9 left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pre-approving depending on whether you want to fix the nit

Zaimwa9
Zaimwa9 previously approved these changes Jul 30, 2026
@khvn26
khvn26 changed the base branch from install-sh to main July 30, 2026 13:21
@khvn26
khvn26 dismissed Zaimwa9’s stale review July 30, 2026 13:21

The base branch was changed.

khvn26 and others added 2 commits July 30, 2026 14:23
Mirrors install.sh: pinned version bumped by release-please, sha256 from
checksums.txt, ~\.local\bin, PATH edited unless told otherwise.

Two Windows-specific wrinkles. PATH goes through the HKCU\Environment registry
key as ExpandString, because [Environment]::SetEnvironmentVariable rewrites
REG_EXPAND_SZ as REG_SZ and would break any %VAR% already in PATH; a dummy
User-scope write then broadcasts WM_SETTINGCHANGE so open shells reread it. And
`iex` cannot pass arguments, so the parameters are backed by the same
FLAGSMITH_* environment variables and the docs show the scriptblock form.

Add-CiPath appends the install dir to $GITHUB_PATH, so a GitHub Actions step
after the install finds the CLI on PATH — which is what the release smoke job
relies on.

beep boop
Co-authored-by: themis-blindfold[bot] <302911107+themis-blindfold[bot]@users.noreply.github.com>

@matthewelwell matthewelwell left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blindly stamping based on previous approval which was dismissed by a rebase 🙈

@khvn26
khvn26 merged commit 8608fb5 into main Jul 30, 2026
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants