feat(website): serve plugin downloads from iracedeck.com (#196)#200
Conversation
Design for #196: serve plugin downloads from iracedeck.com with Firebase redirects to GitHub Release assets, an orchestrator workflow, and a standalone downloads page with version badge.
- Add secrets: inherit to orchestrator workflow_call jobs - Add permissions: contents: write to orchestrator - Rename env var to PUBLIC_IRACEDECK_VERSION for Astro exposure - Document failure handling behavior
Six-task plan covering Firebase redirects, orchestrator workflow, child workflow trigger changes, downloads page, landing page update, and installation docs update.
- Remove platform-specific "double-click to install" from downloads page help text since it doesn't apply to Mirabox - Add missing blank line before jobs: in firebase workflow for consistency with other workflow files
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughRestructures release CI into a tag-triggered orchestrator that runs parallel plugin builds and then deploys the website with an explicit version input. Adds a downloads page and Firebase Hosting 302 redirects that point to GitHub Release assets; the website build bakes the release version into a public env var. Changes
Sequence Diagram(s)sequenceDiagram
participant Git as Git Repository
participant GHA as GitHub Actions Orchestrator
participant BuildSD as Build StreamDeck (release-pack.yml)
participant BuildMB as Build Mirabox (release-pack-dock.yml)
participant Firebase as Firebase Hosting Deployer
participant Release as GitHub Releases
participant Browser as User Browser
Git->>GHA: Push tag v*
activate GHA
GHA->>BuildSD: Call workflow_call (build Stream Deck)
activate BuildSD
GHA->>BuildMB: Call workflow_call (build Mirabox)
activate BuildMB
BuildSD->>Release: Attach Stream Deck artifact
deactivate BuildSD
BuildMB->>Release: Attach Mirabox artifact
deactivate BuildMB
GHA->>Firebase: Call workflow_call with version input
activate Firebase
Firebase->>Firebase: Build website with PUBLIC_IRACEDECK_VERSION
Firebase->>Browser: Deploy site (downloads page + redirects)
deactivate Firebase
deactivate GHA
Browser->>Firebase: Request /downloads/plugin/latest/streamdeck
Firebase->>Release: Redirect 302 to GitHub Release asset
Release->>Browser: Serve asset
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 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 |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (5)
.github/workflows/firebase-hosting-release.yml (1)
8-12: Consider markingversioninput as required forworkflow_call.The
release.ymlorchestrator always passesversion: ${{ github.ref_name }}, so theworkflow_callinput could be marked as required to catch configuration errors early. The current setup works but relies on implicit behavior.Optional: Mark version as required for workflow_call
workflow_call: inputs: version: description: "Release version tag (e.g., v1.7.0)" type: string + required: true🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/firebase-hosting-release.yml around lines 8 - 12, The workflow_call input "version" is not marked required; update the workflow_call inputs block so the "version" input under workflow_call (inputs -> version) includes required: true (keeping description and type: string) to enforce that callers provide version (e.g., github.ref_name) and surface misconfigurations early.docs/superpowers/plans/2026-03-26-download-urls.md (2)
15-15: Minor: Heading level jumps from h1 to h3.Same as the spec document - heading levels should increment by one. Consider using
##for task headings.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/superpowers/plans/2026-03-26-download-urls.md` at line 15, The "Task 1: Firebase Redirects" heading is using h3 (###) while the document jumps from h1 to h3; change that heading to h2 (use ## Task 1: Firebase Redirects) so heading levels increment by one and match the surrounding spec structure.
212-244: Minor discrepancy: Plan content differs slightly from actual implementation.The plan shows the help text as:
"After downloading, double-click the file to install. See the installation guide..."
But the actual
downloads.mdxfile (line 31) has:"After downloading, see the installation guide..."
This is not a problem—the actual implementation is fine—but you may want to update this plan document to match the implementation for consistency if this document serves as ongoing reference.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/superpowers/plans/2026-03-26-download-urls.md` around lines 212 - 244, Update the plan's help paragraph so it matches the actual implementation text in downloads.mdx: replace the current line containing "After downloading, double-click the file to install. See the <a href="/docs/getting-started/installation/">installation guide</a> for detailed instructions." with the shorter copy used in downloads.mdx ("After downloading, see the installation guide...") so the plan and the implemented downloads content stay consistent.docs/superpowers/specs/2026-03-26-download-urls-design.md (2)
15-15: Minor: Heading level jumps from h1 to h3.The static analysis tool flagged that heading levels should increment by one. Line 15 uses
###(h3) directly after the h1 title without an h2 in between.📝 Suggested fix
-### Task 1: Firebase Redirects +## Task 1: Firebase RedirectsApply the same change to other
###headings in this document.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/superpowers/specs/2026-03-26-download-urls-design.md` at line 15, Change the heading level for the "Latest only" heading (currently "### Latest only — only `/downloads/plugin/latest/{platform}` URLs are implemented...") from h3 to h2 and similarly promote any other "###" headings in this document to "##" so heading levels increment sequentially after the h1 title; update the markdown headings (the "###" tokens) throughout the document to "##" to satisfy the static analyzer.
77-82: Consider documenting the partial failure scenario more explicitly.The spec notes that if either build fails, the website deploy is skipped. This is acceptable for preventing broken download links, but it also means:
- If only one platform build fails, neither platform's download link will be updated on the website
- The GitHub Release itself may still have one working asset
This is likely the desired behavior (all-or-nothing deployment), but consider adding a note about manual recovery options (e.g., re-running the workflow after fixing the failed build).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/superpowers/specs/2026-03-26-download-urls-design.md` around lines 77 - 82, Add an explicit note to the design doc describing the partial-failure scenario: in the orchestrator workflow where `build-streamdeck` and `build-mirabox` run in parallel and `deploy-website` waits for both, call out that if one build fails the site deploy is skipped (all-or-nothing) and that a GitHub Release might still contain a single platform asset; document manual recovery steps such as re-running the orchestrator after fixing the failed job or re-running the specific build job then triggering `deploy-website` (or running the orchestrator with the same `version` input), and mention that `secrets: inherit` and `GITHUB_TOKEN`/`FIREBASE_SERVICE_ACCOUNT_IRACEDECK` are required for those recovery actions.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release.yml:
- Around line 7-8: The workflow's permissions block only grants contents: write
but the Firebase action FirebaseExtended/action-hosting-deploy@v0 uses
GITHUB_TOKEN and needs checks: write and pull-requests: write to create check
runs and PR comments; update the permissions block that governs the Firebase
deployment (either the orchestrator permissions block or add a dedicated
permissions block in the firebase-hosting-release workflow) to include checks:
write and pull-requests: write in addition to contents: write so the deployment
action has the required scopes.
In `@packages/website/src/content/docs/docs/getting-started/installation.md`:
- Around line 61-63: Update the "Direct Download from iRaceDeck" section to
remove the word "extract" and clarify that the .sdPlugin file is downloaded
directly: change the sentence referencing ".sdPlugin" to state that users should
download the .sdPlugin file (not extract it) from the iRaceDeck Downloads page
and then import that .sdPlugin into the Mirabox Space app; keep the link to
[iRaceDeck Downloads page] and the import instruction intact.
---
Nitpick comments:
In @.github/workflows/firebase-hosting-release.yml:
- Around line 8-12: The workflow_call input "version" is not marked required;
update the workflow_call inputs block so the "version" input under workflow_call
(inputs -> version) includes required: true (keeping description and type:
string) to enforce that callers provide version (e.g., github.ref_name) and
surface misconfigurations early.
In `@docs/superpowers/plans/2026-03-26-download-urls.md`:
- Line 15: The "Task 1: Firebase Redirects" heading is using h3 (###) while the
document jumps from h1 to h3; change that heading to h2 (use ## Task 1: Firebase
Redirects) so heading levels increment by one and match the surrounding spec
structure.
- Around line 212-244: Update the plan's help paragraph so it matches the actual
implementation text in downloads.mdx: replace the current line containing "After
downloading, double-click the file to install. See the <a
href="/docs/getting-started/installation/">installation guide</a> for detailed
instructions." with the shorter copy used in downloads.mdx ("After downloading,
see the installation guide...") so the plan and the implemented downloads
content stay consistent.
In `@docs/superpowers/specs/2026-03-26-download-urls-design.md`:
- Line 15: Change the heading level for the "Latest only" heading (currently
"### Latest only — only `/downloads/plugin/latest/{platform}` URLs are
implemented...") from h3 to h2 and similarly promote any other "###" headings in
this document to "##" so heading levels increment sequentially after the h1
title; update the markdown headings (the "###" tokens) throughout the document
to "##" to satisfy the static analyzer.
- Around line 77-82: Add an explicit note to the design doc describing the
partial-failure scenario: in the orchestrator workflow where `build-streamdeck`
and `build-mirabox` run in parallel and `deploy-website` waits for both, call
out that if one build fails the site deploy is skipped (all-or-nothing) and that
a GitHub Release might still contain a single platform asset; document manual
recovery steps such as re-running the orchestrator after fixing the failed job
or re-running the specific build job then triggering `deploy-website` (or
running the orchestrator with the same `version` input), and mention that
`secrets: inherit` and `GITHUB_TOKEN`/`FIREBASE_SERVICE_ACCOUNT_IRACEDECK` are
required for those recovery actions.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: a7bd0e66-12fd-4abc-ac11-daaba7b78f7e
📒 Files selected for processing (12)
.github/workflows/firebase-hosting-release.yml.github/workflows/release-pack-dock.yml.github/workflows/release-pack.yml.github/workflows/release.ymldocs/superpowers/plans/2026-03-26-download-urls.mddocs/superpowers/specs/2026-03-26-download-urls-design.mdpackages/website/astro.config.mjspackages/website/firebase.jsonpackages/website/src/content/docs/docs/getting-started/installation.mdpackages/website/src/content/docs/downloads.mdxpackages/website/src/content/docs/index.mdxpackages/website/src/styles/custom.css
- Add checks: write and pull-requests: write to orchestrator permissions for FirebaseExtended/action-hosting-deploy - Mark workflow_call version input as required - Fix Mirabox install wording (remove incorrect "extract")
Related Issue
Fixes #196
What changed?
firebase.jsonfor/downloads/plugin/latest/streamdeckand/downloads/plugin/latest/mirabox, pointing to GitHub Releaselatest/downloadURLsrelease.ymltriggers onv*tags, runs Stream Deck and Mirabox builds in parallel, then deploys the website after both completerelease-pack.yml,release-pack-dock.yml, andfirebase-hosting-release.ymlfrompush: tagstoworkflow_call(+workflow_dispatchfor manual runs)firebase-hosting-release.ymlpasses the tag version asPUBLIC_IRACEDECK_VERSIONenv var, baked into the website at build time/downloads/with download buttons for both platforms, version badge, and marketplace fallback links/downloads/Implementation decisions (deviations from issue)
/downloads/plugin/v1.7.0/streamdeck) are deferred; only/latest/is implementedworkflow_dispatchversion input — added optionalversioninput tofirebase-hosting-release.ymlfor manual testing convenience (not in original issue)How to test
pnpm --filter @iracedeck/website build— should succeed with 47 pages/downloads/page renders with two download cardsrelease.ymlvia a test tag to verify the orchestrator calls child workflows correctlycurl -I https://iracedeck.com/downloads/plugin/latest/streamdeckshould return 302Checklist
Summary by CodeRabbit
New Features
Documentation