Add Homebrew cask and document brew install - #284
Conversation
Pins the notarized universal DMG from GitHub Releases. Declares auto_updates because FreeFlow ships its own in-app updater, and a minimum of macOS 13 to match the -target macosx13.0 build flag. The zap paths are the four locations a release build actually writes: Application Support/FreeFlow, plus the Caches, HTTPStorages, and Preferences entries for com.zachlatta.freeflow.
The cask pins an exact version and sha256, so without this it goes stale on the next tag and brew serves the previous build.
📝 WalkthroughWalkthroughAdds a Homebrew cask for FreeFlow, automates pinned version and checksum updates during releases, and documents Homebrew installation alongside direct downloads. ChangesHomebrew distribution
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant ReleaseWorkflow
participant GitHubMain
participant Homebrew
participant FreeFlowApp
ReleaseWorkflow->>GitHubMain: update and push cask version and checksum
Homebrew->>GitHubMain: resolve cask metadata
Homebrew->>FreeFlowApp: download and install FreeFlow.app
Possibly related issues
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
.github/workflows/release.yml (1)
156-173: 🩺 Stability & Availability | 🔵 TrivialSerialize release-time pushes to
main.Two releases running concurrently can both modify the same base revision; one push will then fail, leaving the newer published release without a matching cask update. Confirm this workflow already has a non-canceling concurrency group; otherwise add one or retry after rebasing.
🤖 Prompt for 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. In @.github/workflows/release.yml around lines 156 - 173, The release workflow’s cask update block must serialize pushes to main so concurrent releases cannot race on the same revision. Inspect the workflow-level concurrency configuration and ensure it uses a shared release group with cancellation disabled; if that is already present, preserve it, otherwise add the non-canceling concurrency settings rather than changing the checkout or commit logic.
🤖 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 157-160: Update the missing-Casks/freeflow.rb guard in the release
workflow to fail the step instead of exiting successfully when the cask file is
absent. Preserve the diagnostic message, but use a nonzero exit status so
deleted or renamed casks cannot produce a successful release.
In `@Casks/freeflow.rb`:
- Line 5: Align the release workflow’s tag validation with the cask URL’s
v-prefixed convention: update the tag handling in release.yml to accept only
tags in the v#{version} form, while preserving the existing version extraction
and release behavior.
In `@README.md`:
- Line 32: Replace the “click here” link text in the FreeFlow installation
instructions with descriptive text such as “download FreeFlow.dmg,” while
preserving the existing release URL and surrounding installation guidance.
---
Nitpick comments:
In @.github/workflows/release.yml:
- Around line 156-173: The release workflow’s cask update block must serialize
pushes to main so concurrent releases cannot race on the same revision. Inspect
the workflow-level concurrency configuration and ensure it uses a shared release
group with cancellation disabled; if that is already present, preserve it,
otherwise add the non-canceling concurrency settings rather than changing the
checkout or commit logic.
🪄 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 Plus
Run ID: fe9af1c6-712e-4ee3-9e3c-55a680081610
📒 Files selected for processing (3)
.github/workflows/release.ymlCasks/freeflow.rbREADME.md
|
@ChaoticQubit This appears to address #185. Would you add |
The version-stamp step leaves Info.plist dirty, so a plain 'git checkout main' aborts whenever main has moved since the tag. Notarization takes long enough to make that a realistic race, so force the switch, re-read main on each attempt, and retry a rejected push. Also fail rather than pass when the cask file is missing: the release is already published by that point, so a silent skip leaves Homebrew serving the previous build behind a green workflow.
|
Thanks both. Round-up of the review: @TyceHerrman - good catch, added CodeRabbit, silently skipped cask update - valid, fixed in 3142ad0. Digging into it surfaced a worse bug in the same block that the guard was masking. The earlier "Stamp app version" step Notarization takes minutes, so CodeRabbit, serialize release-time pushes - real risk, handled by that same retry rather than a CodeRabbit, tag convention mismatch - I don't think this one holds; details in the thread. Short version: the trigger is CodeRabbit, "click here" link text - valid, applied in a519e03. I tested the reworked release step rather than eyeballing it: extracted the step's shell body straight out of the YAML and ran it against a scratch repo covering moved- |
2 participants
Closes #185
Adds Homebrew as an install option:
The cask points at the notarized universal DMG this repo already publishes to GitHub Releases, so nothing about the build or signing setup changes.
Commits, each independently droppable:
Casks/freeflow.rb- the cask itself.release.yml- the cask pins an exactversionandsha256, so without this it goes stale on the next tag and Homebrew keeps serving the previous build. Uses thecontents: writepermission the workflow already has. No new secrets, no new actions.Why each stanza
depends_on macos: :ventura-target *-apple-macosx13.0in theMakefileauto_updates trueUpdateManagerdownloads and self-installs. Without this,brew upgradeand the in-app updater fight over/Applications/FreeFlow.appuninstall quit:/login_item:SMAppService.mainAppzap trash:Application Support/FreeFlowplus theCaches,HTTPStoragesandPreferencesentries forcom.zachlatta.freeflowlivecheck+strategy :github_latest/releases/latestreturnsv1.2.0and correctly skips thedevprereleaseVerification
Cask:
brew fetch --cask- checksum verified against the published v1.2.0 DMGbrew info --cask- resolves to1.2.0 (auto_updates),Required: macOS >= 13,FreeFlow.app (App)brew install --cask --dry-run- cleanCasks/freeflow.rbat the repo rootaccepted / source=Notarized Developer IDand stapledRelease step, exercised by extracting the step's shell body straight out of the YAML and running it against a scratch repo:
mainmoved since the tag,Info.plistleft dirty by the version-stamp step - switches and bumps correctlymain's intervening commit preservedversionand asha256matching the DMG byte for bytemain- exits 1 with an::error::annotationOne gap worth flagging: I could not run
brew style/brew auditlocally, because the Homebrew install on my machine is read-only and can't bootstrap its developer gems. The cask loads and resolves correctly through Homebrew's own DSL, and its stanza order and content follow the Cask Cookbook and existing GitHub-hosted casks, but it has not been through the official linters.Open question
This puts the cask in this repo, so the repo doubles as a tap. That works today, but it probably isn't the end state -
brew taphas to clone 34.7 MB of app source to deliver a 29-line file.I opened #283 to discuss in-repo tap vs a dedicated
homebrew-freeflowtap vs submitting toHomebrew/homebrew-cask. FreeFlow clears the homebrew-cask notability bar comfortably. The cask file is identical in all three cases, so this PR isn't wasted work either way - happy to follow up with whichever you prefer.