Iter-9: realign admin deploy with bunny canonical pattern (ghcr.io)#10
Conversation
…self-build Workflow: - Switch admin image hosting from bunny container registry to ghcr.io (drops BUNNY_REGISTRY/USERNAME/PASSWORD secrets; GITHUB_TOKEN suffices) - Replace curl-based deploy trigger with BunnyWay/actions/container-update-image - Use secrets.BUNNYNET_API_KEY (matches bunny docs and existing secret name); align build-homepage on the same secret for consistency - Gate build-admin on vars.APP_ID being set so the job skips cleanly before the admin Magic Container app is provisioned - Add packages:write permission for the ghcr push Dockerfile: - Set placeholder env in builder stage so Next's build-time page-data collection doesn't fail when run outside CI's verify-step env injection. ENV doesn't cross FROM boundaries — values stay in builder, runner uses real container env vars. Iteration: iter-9 (go live). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ 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: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis PR updates deployment infrastructure for two services: the homepage now uses the correct ChangesHomepage Static Deployment
Admin Container Deployment
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/deploy.yml (1)
91-144:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winUpdate README.md and kb/runbook-go-live.md to match the new secret/variable names.
The workflow now reads
secrets.BUNNYNET_API_KEYandvars.APP_ID, butREADME.md(lines 64-71) still documentssecrets.BUNNY_API_KEYandvars.ADMIN_APP_ID, andkb/runbook-go-live.md(line 253) likewise referencesADMIN_APP_ID. Per the PR objectives the workflow names are intentional (matching the existing repo secret/variable), so the docs are the side that's stale. Without an update, an operator following the runbook to reprovision secrets/vars after a token rotation or repo migration will set the wrong names andbuild-adminwill silently skip (because of thevars.APP_ID != ''gate at line 93) or the homepage upload will fail authentication.A
vars.APP_IDnamed that generically also won't scale — if a second Magic Container app is ever added (e.g. a worker), you'll likely wantADMIN_APP_IDto disambiguate. Worth considering renaming the GitHub variable now while there's only one app, but at minimum sync the docs.🤖 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/deploy.yml around lines 91 - 144, Docs are out of sync with the workflow: update README and kb/runbook-go-live.md to reference the workflow's actual secret/variable names (secrets.BUNNYNET_API_KEY and vars.APP_ID) instead of the old names (secrets.BUNNY_API_KEY and vars.ADMIN_APP_ID) so the build-admin job's conditions and the Magic Container upload authenticate correctly; while editing, optionally add a note suggesting renaming vars.APP_ID to a more specific name like ADMIN_APP_ID if you plan multiple Magic Container apps in future to avoid ambiguity.
🤖 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/deploy.yml:
- Around line 137-144: The workflow uses the third-party action reference
BunnyWay/actions/container-update-image@main which is a moving ref and gives
deploy-time access to secrets (secrets.BUNNYNET_API_KEY) — replace the `@main` tag
with the full 40-character commit SHA for
BunnyWay/actions/container-update-image to pin the exact code used when updating
the wardrobe-assistants-admin container (container: wardrobe-assistants-admin,
image_tag: ${{ github.sha }}); add a short comment like “# vX.Y.Z” for
readability and update the SHA via Dependabot or PRs, and confirm the pinned
commit is compatible with future Node.js runtime changes referenced in
BunnyWay/actions#25.
---
Outside diff comments:
In @.github/workflows/deploy.yml:
- Around line 91-144: Docs are out of sync with the workflow: update README and
kb/runbook-go-live.md to reference the workflow's actual secret/variable names
(secrets.BUNNYNET_API_KEY and vars.APP_ID) instead of the old names
(secrets.BUNNY_API_KEY and vars.ADMIN_APP_ID) so the build-admin job's
conditions and the Magic Container upload authenticate correctly; while editing,
optionally add a note suggesting renaming vars.APP_ID to a more specific name
like ADMIN_APP_ID if you plan multiple Magic Container apps in future to avoid
ambiguity.
🪄 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
Run ID: 78bbdd43-c6cf-4dee-95dd-cf2fce2d7682
📒 Files selected for processing (2)
.github/workflows/deploy.ymlapps/admin/Dockerfile
| - name: Roll admin Magic Container to new image | ||
| if: steps.changes.outputs.app == 'true' | ||
| env: | ||
| BUNNY_API_KEY: ${{ secrets.BUNNY_API_KEY }} | ||
| ADMIN_APP_ID: ${{ vars.ADMIN_APP_ID }} | ||
| run: | | ||
| curl -fsS -X POST \ | ||
| -H "AccessKey: $BUNNY_API_KEY" \ | ||
| "https://api.bunny.net/magic-containers/apps/$ADMIN_APP_ID/deploy" | ||
| uses: BunnyWay/actions/container-update-image@main | ||
| with: | ||
| app_id: ${{ vars.APP_ID }} | ||
| api_key: ${{ secrets.BUNNYNET_API_KEY }} | ||
| container: wardrobe-assistants-admin | ||
| image_tag: ${{ github.sha }} |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
GitHub Actions security hardening pin third-party action commit SHA
💡 Result:
To harden GitHub Actions security, especially for third-party actions, pin them to a full-length (40-character) commit SHA instead of mutable tags or branches. This prevents supply chain attacks where tags are rewritten or repositories compromised to inject malicious code, as SHAs are immutable [1][2][3]. Example workflow change: Before: uses: some/action@v1 After: uses: some/action@692973e3d937129bcbf40652eb9f2f61becf3332 # v1.0.0 [1][3][4] How to find the SHA [3]: 1. Go to the action's repo (e.g., https://github.com/owner/repo for owner/repo). 2. Switch to the tag/branch (e.g., v1). 3. Copy the full commit SHA from the commit page. Or run: git ls-remote --tags https://github.com/owner/repo.git v1 [4]. Or check a workflow run log under "Set up job" for the resolved SHA [3]. Add a comment with the version for reference [5][4][6]. Use Dependabot to update pinned SHAs automatically [1]. Enforce via policies: At repo/org/enterprise level, enable "Require full commit SHA for actions" in Actions settings > General > Policies. Unpinned workflows fail [2][7]. Prefer verified creators from Marketplace [1]. Tools like GitHub Actions Lockfile can generate/verify lockfiles with SHAs [8].
Citations:
- 1: https://docs.github.com/en/actions/reference/security/secure-use
- 2: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
- 3: https://stackoverflow.com/questions/78903499/how-do-i-pin-an-action-to-a-specific-sha
- 4: Pin all GitHub Actions to immutable SHA commits for supply chain security github/gh-aw#5691
- 5: Pin GitHub Actions to commit SHAs in release workflow github/gh-aw#10021
- 6: Pin third-party GitHub Actions to commit SHAs sveltejs/kit#15528
- 7: https://dev.to/ciberconscientes/github-actions-why-you-should-pin-your-actions-to-a-specific-version-1513
- 8: https://github.com/marketplace/actions/github-actions-lockfile
🌐 Web query:
BunnyWay/actions container-update-image action GitHub repository
💡 Result:
The BunnyWay/actions/container-update-image is a GitHub Action within the BunnyWay/actions repository [1]. It updates container images for Bunny.net's Magic Containers platform, automating rolling updates after building and pushing new Docker images [2][3]. Repository details: https://github.com/BunnyWay/actions (created 2024-08-09, last push 2026-03-27, 13 stars, JavaScript primary language) [1]. The action is in the container-update-image folder, with its own documentation there [1]. Latest release: container-update-image_0.2.1 (2026-03-27) [1][4]. Usage example from official Bunny.net docs [2]: - name: Update container image on Magic Containers uses: BunnyWay/actions/container-update-image@main with: app_id: ${{ vars.APP_ID }} api_key: ${{ secrets.BUNNYNET_API_KEY }} container: app image_tag: "${{ github.sha }}" Required inputs [2]: - app_id: Magic Containers App ID - api_key: Bunny.net API key (no sub-user support) - container: Container name - image_tag: New image tag Recent updates include support for optional image_digest [5], removing imageDigest when updating imageTag [4], Node.js 20 (issue open for upgrade to 24) [6]. It's used in workflows for Magic Containers deployments [7].
Citations:
- 1: https://github.com/BunnyWay/actions
- 2: https://docs.bunny.net/magic-containers/deploy-with-github-actions
- 3: https://docs.bunny.net/magic-containers/update
- 4: https://github.com/BunnyWay/actions/releases
- 5: https://github.com/BunnyWay/actions/actions
- 6: Update to Node.js 24 runtime BunnyWay/actions#25
- 7: https://docs.bunny.net/magic-containers/guides/simple-go-api
🌐 Web query:
GitHub Actions Node.js 20 deprecated June 2026 timeline
💡 Result:
GitHub Actions is deprecating Node.js 20 support on hosted runners. Starting June 2nd, 2026, runners will default to Node.js 24 for JavaScript actions.[1][2] Users can opt out temporarily by setting ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true in their workflow or runner environment, but Node 20 will be fully removed later in fall 2026.[1] Node.js 20 reaches upstream EOL on April 30, 2026.[3] Warnings already appear for actions using Node 20, like actions/checkout@v4.[4] Newer runner versions (e.g., v2.328.0+) support both Node 20 and 24, defaulting to 20 currently.[1] To test Node 24 early, set FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true.[1] Action maintainers should update to Node 24 (via actions configuration).[1] Users should pin latest action versions supporting Node 24. setup-node@v4+ supports Node 22/24.[5] ubuntu-latest (ubuntu-24.04) currently defaults to Node 20.x, discussions ongoing to update post-EOL.[3]
Citations:
- 1: https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/
- 2: Update Node.js 20 deprecation date to June 2nd, 2026 actions/runner#4258
- 3: ubuntu-latest default Node.js 20.20.2 unsupported actions/runner-images#13833
- 4: [BUG] Node.js 20 actions are deprecated. Deadline 2nd of June 2026 SAP/architecture-center#859
- 5: https://github.com/actions/setup-node
🌐 Web query:
GitHub Actions node20 runtime deprecation schedule
💡 Result:
GitHub Actions Node 20 runtime deprecation schedule, as of today's date (2026-05-05): Node.js 20 reaches end-of-life (EOL) on 2026-04-30 [1][2]. Deprecation process started due to EOL. Runners currently default to Node 20 but support Node 24 [1]. Key dates: - Beginning June 2, 2026: Runners will use Node 24 by default for JavaScript actions. Workflows can opt out to continue using Node 20 by setting ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true env var (until full removal) [1][3]. - Later in fall 2026 (around September/October): Node 20 fully removed from runners [1][4]. Editor's note on the changelog updated February 25, 2026, confirms migration to June 2026 [1]. To test Node 24 early: Set FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true [1]. Action maintainers should update actions.yml to 'node24' [1]. Ubuntu-latest currently defaults to Node 20.20.2, discussions ongoing to update post-EOL, ideally aligning with June 2 [2].
Citations:
- 1: https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/
- 2: ubuntu-latest default Node.js 20.20.2 unsupported actions/runner-images#13833
- 3: Update Node.js 20 deprecation date to June 2nd, 2026 actions/runner#4258
- 4: Update action from Node.js 20 to Node.js 24 before GitHub deprecation deadline game-ci/unity-builder#826
Pin BunnyWay/actions/container-update-image to a commit SHA instead of @main.
@main is a moving reference: any push to that branch (including a compromised one) immediately runs in your release pipeline with access to secrets.BUNNYNET_API_KEY and the ability to roll the production Magic Container. GitHub's hardening guide and OpenSSF Scorecard both recommend pinning third-party actions to a full 40-character commit SHA. You can leave a # v… comment alongside for readability, and Dependabot can still bump the SHA on its schedule.
A secondary concern: per BunnyWay/actions#25, container-update-image currently declares using: 'node20'. GitHub is forcing Node.js 20 to Node.js 24 starting June 2, 2026 (Node.js 20 reaches EOL April 30, 2026). Pinning to a specific SHA makes that future breakage visible and controllable rather than a surprise mid-deploy.
🔒 Suggested change
- uses: BunnyWay/actions/container-update-image@main
+ # pin: replace <sha> with the full commit SHA of the desired version
+ uses: BunnyWay/actions/container-update-image@<sha> # main as of YYYY-MM-DD🤖 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/deploy.yml around lines 137 - 144, The workflow uses the
third-party action reference BunnyWay/actions/container-update-image@main which
is a moving ref and gives deploy-time access to secrets
(secrets.BUNNYNET_API_KEY) — replace the `@main` tag with the full 40-character
commit SHA for BunnyWay/actions/container-update-image to pin the exact code
used when updating the wardrobe-assistants-admin container (container:
wardrobe-assistants-admin, image_tag: ${{ github.sha }}); add a short comment
like “# vX.Y.Z” for readability and update the SHA via Dependabot or PRs, and
confirm the pinned commit is compatible with future Node.js runtime changes
referenced in BunnyWay/actions#25.
Better Auth's enableTwoFactor requires an active session — the CLI seed script was calling it with empty Headers, getting Unauthorized, and leaving newly-created users without TOTP enrolled. Fix: signInEmail to obtain the session cookie, then pass that cookie to enableTwoFactor. Tested locally: admin user james@ractive.ch created on the prod DB with TOTP enrolled. QR + backup codes printed. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1 participant
Summary
BunnyWay/actions/container-update-image@mainfor the container roll.secrets.BUNNYNET_API_KEY(matches bunny docs and the secret name that already existed in the repo since 2026-04-20). Alignedbuild-homepageon the same secret so there's one bunny API key, one rotation point.build-adminonvars.APP_ID != ''so it skips cleanly before the admin Magic Container exists.permissions: { contents: read, packages: write }for the ghcr push.next build(page-data collection) succeeds when the Dockerfile is run outside the verify-step's env injection. ENV doesn't cross FROM boundaries — runtime image is unaffected.Pre-merge state set up by the iter-9 cutover
Already provisioned and ready for this PR's deploy:
wardrobe-assistants-admin(idh4vme6Uhod4W3Yu)wa-admin-prod(iddb_01KQV95KJ611YYT48VSZKHC495); migrations applied; full+RO tokens mintedadmin.wardrobe-assistants.ch→mc-r6f39iacv2.b-cdn.netvars.APP_ID = h4vme6Uhod4W3Yu;BUNNYNET_API_KEYalignedWhat happens on merge
verifyruns (typecheck + Vitest + both Next builds with placeholders) — green expected.build-homepagerebuilds + uploads to bunny Storage (already at parity from manual upload, will be a no-op refresh + cache purge).build-adminbuilds the admin Docker image, pushes toghcr.io/ractive/wardrobe-assistants-admin:<sha>and:latest, thenBunnyWay/actions/container-update-imagerolls the Magic Container to the new tag.Test plan
verify,build-homepage,build-adminall pass.curl -I https://admin.wardrobe-assistants.ch/login→ 200.https://wardrobe-assistants.chcontinues to serve the homepage from the new Pull Zone (no regression).🤖 Generated with Claude Code
Summary by CodeRabbit