Deploy on main.

[kixelated]

No description provided.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

---

Walkthrough

A new GitHub Actions workflow is added at .github/workflows/deploy.yml named deploy. It triggers on pushes to the main branch and defines a single job running on ubuntu-latest with a 15-minute timeout and per-branch concurrency cancellation. The job checks out the repository, sets up Bun v1.3.4, runs bun install --frozen-lockfile, bun run check, bun astro build, and bun wrangler deploy --env live, exporting CLOUDFLARE_API_TOKEN from repository secrets.

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	No description was provided by the author, making it impossible to assess relevance to the changeset.	Add a pull request description explaining the deployment workflow, its purpose, and any configuration details.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Deploy on main' directly describes the workflow's purpose, which is to set up automated deployment on pushes to the main branch.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch auto-deploy

---

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

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (4)

.github/workflows/deploy.yml (4)

8-9: Consider adding timeout-minutes to the job.

Without a timeout, a hung wrangler deploy or slow astro build will consume runner minutes until the default GitHub Actions cap (6 hours) is hit. A realistic ceiling (e.g. 10–15 minutes) keeps costs and feedback loops bounded.

⏱️ Proposed timeout

   deploy:
     runs-on: ubuntu-latest
+    timeout-minutes: 15

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/deploy.yml around lines 8 - 9, The deploy job currently
lacks a timeout which can let long-running commands like `wrangler deploy` or
`astro build` consume runner minutes; add a `timeout-minutes` setting to the
`deploy` job (e.g., `timeout-minutes: 15`) so the job terminates after a
reasonable ceiling, placing the `timeout-minutes` key alongside `runs-on` in the
`deploy` job definition to bound execution time.

---

7-9: Declare explicit permissions to enforce least privilege.

The workflow currently inherits the repository's default token permissions. Explicitly restricting to contents: read (the minimum needed for actions/checkout) prevents the GITHUB_TOKEN from being misused if any step is compromised.

🛡️ Proposed permissions block

 jobs:
   deploy:
     runs-on: ubuntu-latest
+    permissions:
+      contents: read

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/deploy.yml around lines 7 - 9, Add an explicit top-level
permissions block to the workflow to enforce least privilege; modify the
workflow containing the jobs.deploy and runs-on keys to include permissions:
contents: read (so GITHUB_TOKEN only has read access to repository contents for
actions/checkout) and remove reliance on repository default token permissions.

---

7-9: Add a concurrency group to prevent overlapping deployments.

Without it, two rapid pushes to main will queue two independent deployment jobs that can run in parallel, potentially racing to update the live Cloudflare environment. A cancel-in-progress strategy ensures only the latest commit is ever deploying.

⚙️ Proposed concurrency block

 jobs:
   deploy:
     runs-on: ubuntu-latest
+    concurrency:
+      group: deploy-live
+      cancel-in-progress: true

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/deploy.yml around lines 7 - 9, Add a GitHub Actions
concurrency block to the deploy job to prevent overlapping deployments: in the
jobs.deploy definition (the job named "deploy" with runs-on: ubuntu-latest) add
a concurrency mapping that sets a group (e.g., using github.ref or
github.workflow + github.ref to scope to the branch) and cancel-in-progress:
true so any in-progress deploy is cancelled when a new run for the same group
starts.

---

12-13: Pin action refs to full commit SHAs to guard against supply-chain mutations.

actions/checkout@v4 and oven-sh/setup-bun@v2 are floating mutable tags; a compromised or force-pushed tag would silently execute arbitrary code in this deployment workflow. Pinning to a specific commit SHA is the recommended hardening approach.

🔒 Example with SHA-pinned refs

-      - uses: actions/checkout@v4
+      - uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5  # v4
-      - uses: oven-sh/setup-bun@v2
+      - uses: oven-sh/setup-bun@3d267786b128fe76c2f16a390aa2448b815359f3  # v2

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/deploy.yml around lines 12 - 13, The workflow uses mutable
refs actions/checkout@v4 and oven-sh/setup-bun@v2; replace those tag refs with
the corresponding full commit SHAs (e.g., actions/checkout@<full-commit-sha> and
oven-sh/setup-bun@<full-commit-sha>) to pin the actions and prevent supply-chain
mutation. Locate the two uses lines in the deploy workflow and update each
`uses:` value to the full commit SHA for the exact release you want to lock,
then commit the change and verify the workflow runs as expected.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In @.github/workflows/deploy.yml:
- Around line 8-9: The deploy job currently lacks a timeout which can let
long-running commands like `wrangler deploy` or `astro build` consume runner
minutes; add a `timeout-minutes` setting to the `deploy` job (e.g.,
`timeout-minutes: 15`) so the job terminates after a reasonable ceiling, placing
the `timeout-minutes` key alongside `runs-on` in the `deploy` job definition to
bound execution time.
- Around line 7-9: Add an explicit top-level permissions block to the workflow
to enforce least privilege; modify the workflow containing the jobs.deploy and
runs-on keys to include permissions: contents: read (so GITHUB_TOKEN only has
read access to repository contents for actions/checkout) and remove reliance on
repository default token permissions.
- Around line 7-9: Add a GitHub Actions concurrency block to the deploy job to
prevent overlapping deployments: in the jobs.deploy definition (the job named
"deploy" with runs-on: ubuntu-latest) add a concurrency mapping that sets a
group (e.g., using github.ref or github.workflow + github.ref to scope to the
branch) and cancel-in-progress: true so any in-progress deploy is cancelled when
a new run for the same group starts.
- Around line 12-13: The workflow uses mutable refs actions/checkout@v4 and
oven-sh/setup-bun@v2; replace those tag refs with the corresponding full commit
SHAs (e.g., actions/checkout@<full-commit-sha> and
oven-sh/setup-bun@<full-commit-sha>) to pin the actions and prevent supply-chain
mutation. Locate the two uses lines in the deploy workflow and update each
`uses:` value to the full commit SHA for the exact release you want to lock,
then commit the change and verify the workflow runs as expected.