feat(sparkle-release): support dedicated updates repository - #2
Conversation
Allow callers to host Sparkle ZIP/delta download URLs and appcast Pages on a separate updates repo while keeping human release notes / DMGs on the app repo.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthrough
ChangesSparkle updates repository support
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant CallerWorkflow
participant SparkleRelease
participant GitHubAPI
participant FeedRepository
participant DownloadRepository
CallerWorkflow->>SparkleRelease: Configure updates repository and token
SparkleRelease->>GitHubAPI: Load appcast and prior tag metadata
SparkleRelease->>DownloadRepository: Retrieve prior release ZIPs
SparkleRelease->>SparkleRelease: Generate and sign appcast.xml
SparkleRelease->>FeedRepository: Push appcast.xml to gh-pages
Possibly related PRs
Suggested reviewers: 🚥 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 |
There was a problem hiding this comment.
Pull request overview
Adds support to actions/sparkle-release for hosting Sparkle appcast + ZIP/deltas in a dedicated “updates” repository (instead of the caller repo), while documenting the recommended DMG-vs-updates split.
Changes:
- Document using a dedicated Sparkle updates repository and its required permissions/token.
- Add
updates-repository/updates-tokeninputs and route appcast loading/publishing and download URL generation to the selected repo. - Prefer prior ZIPs from the updates repo for delta generation, with fallback to the caller repo for pre-cutover history.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| README.md | Documents the dedicated updates-repository setup, example usage, and permissions. |
| actions/sparkle-release/action.yml | Adds inputs + logic to resolve feed/download repos, read/write appcast from the chosen repo, and generate enclosure URLs against the chosen download repo. |
Comments suppressed due to low confidence (1)
actions/sparkle-release/action.yml:98
- When
updates-repositoryis set, this step only requiresupdates-tokenifpublish-appcastis true. But later steps also use the token to readappcast.xmlfromFEED_REPOand to list/download prior ZIPs fromDOWNLOAD_REPO. Sincegithub.tokenis repo-scoped, those cross-repo reads will fail withoutupdates-token, preventing delta history from being loaded.
Consider requiring updates-token whenever updates-repository is set (or alternatively implement an unauthenticated/public-read path).
if [[ "$PUBLISH_APPCAST" == "true" && -z "$UPDATES_TOKEN" ]]; then
echo "updates-token is required when updates-repository is set and publish-appcast is true"
exit 1
fi
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| description: >- | ||
| Token with contents:write on updates-repository (required when | ||
| updates-repository is set and publish-appcast is true). Public reads may | ||
| fall back to github.token. |
Summary
updates-repository+updates-tokentoactions/sparkle-releasegh-pages, point enclosure URLs at its releases, and prefer its prior ZIPs for deltas (fallback to caller repo for pre-cutover history)Test plan
release.ymlwithupdates-repository: thaw-app/updatesupdatesSummary by CodeRabbit
New Features
release-html-url.Documentation