feat: add ci/cd for builds

[evan-taylor]

Linked Issues

Closes #
Linear: (e.g., POLY-123)

Summary

Briefly explain the change and why.

How to Test

Steps to verify locally:

• npm run lint
• npm run typecheck
• npm test
• Manual flow:
  1. npm run dev:backend (in terminal A)
  2. npm run dev (in terminal B)
  3. Verify the change: <describe expected behavior/screens>

Checklist

• Tests added/updated (if applicable)
• Lint/tests pass locally (npm run lint)
• Docs updated (README/ADR/changelog if needed)
• Follows conventional commit format
• No merge conflicts with dev

Screenshots / Demos

(if UI or visible behavior - attach images, videos, or GIFs)

Summary by CodeRabbit

• Chores
  • Added automated iOS TestFlight build workflow that triggers on updates to the main branch
  • Added manual iOS TestFlight build workflow for on-demand development testing

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
poly-buys	Ready	Preview, Comment	Apr 16, 2026 10:56pm

[coderabbitai]

Warning

Rate limit exceeded

@evan-taylor has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 54 minutes and 11 seconds before requesting another review.

Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 54 minutes and 11 seconds.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: dcfdc499-5993-4bc6-be34-93d1e9bc6445

📥 Commits

Reviewing files that changed from the base of the PR and between d5a7d80 and cec911c.

📒 Files selected for processing (1)

• .github/workflows/ios-release-main.yml

📝 Walkthrough

Walkthrough

Two new GitHub Actions workflows are introduced for iOS builds and TestFlight submissions. The development workflow (ios-release-dev.yml) is manually triggered via workflow_dispatch, while the main workflow (ios-release-main.yml) automatically triggers on pushes to the main branch. Both workflows check out the repository, set up Node.js 20.19.4, configure Expo/EAS, install dependencies, build iOS IPAs using EAS with the production profile, submit to TestFlight, and upload artifacts.

Changes

Cohort / File(s)	Summary
iOS TestFlight Workflows .github/workflows/ios-release-dev.yml, .github/workflows/ios-release-main.yml	Two new GitHub Actions workflows for building and submitting iOS apps to TestFlight. Dev workflow is manually triggered; main workflow auto-triggers on pushes to main. Both use Node.js 20.19.4, Expo/EAS setup, build iOS IPAs with production profile, submit to TestFlight, and upload build artifacts with configurable retention policies.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 Hop, build, and fly so high,
Two workflows reach the TestFlight sky,
Dev and main, both set to go,
iOS apps put on a show! ✨📱

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description consists entirely of unused template placeholders with no actual content filled in—missing linked issues, summary explanation, how to test instructions, and test verification.	Fill in the description with actual content: specify linked issues, explain why CI/CD workflows were added, describe testing procedures, and detail what was implemented in the iOS release workflows.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'feat: add ci/cd for builds' clearly and concisely describes the main change—adding GitHub Actions workflows for iOS TestFlight builds and submission.
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
• Commit unit tests in branch evan/ci-cd

---

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]

Actionable comments posted: 1

🧹 Nitpick comments (2)

.github/workflows/ios-release-main.yml (2)

27-31: Pin eas-version instead of tracking latest.

eas-version: latest means a new EAS CLI release can silently change build/submit behavior (breaking flags, schema changes, etc.) on your next push to main. Pin to a known-good version (e.g. eas-version: 16.x.x) and bump intentionally. Same comment applies to ios-release-dev.yml line 29.

🤖 Prompt for AI Agents

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

In @.github/workflows/ios-release-main.yml around lines 27 - 31, Replace the
eas-version: latest setting in the step that uses expo/expo-github-action@v8
with a pinned, known-good EAS CLI version (for example eas-version: 16.x.x) so
builds don't silently change; update the same eas-version pin in the
corresponding dev workflow's expo/expo-github-action@v8 step as well and commit
the changed version string rather than leaving it as "latest".

---

11-15: Add a least-privilege permissions: block.

Neither workflow declares permissions:, so the GITHUB_TOKEN inherits the repo/org default (often read/write). For a build+submit workflow that only needs to read the repo and upload artifacts, scope it explicitly.

🛡️ Suggested diff

 jobs:
   build-and-submit:
     name: Build and submit iOS
     runs-on: macos-latest
     timeout-minutes: 90
+    permissions:
+      contents: read

🤖 Prompt for AI Agents

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

In @.github/workflows/ios-release-main.yml around lines 11 - 15, The workflow
lacks an explicit least-privilege permissions block; add a top-level
permissions: entry for this workflow that scopes GITHUB_TOKEN to only what the
build-and-submit job needs (e.g. set contents: read and artifacts: write and
packages: write), and if your submission step uses OIDC include id-token: write;
add this permissions block at the top of the workflow YAML so the
build-and-submit job (name "Build and submit iOS") uses the restricted token and
adjust scopes if any steps require id-token or additional access.

🤖 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/ios-release-main.yml:
- Around line 3-5: The workflow currently triggers on "on: push" with "branches:
[main]" which runs TestFlight builds for every commit; change the trigger
configuration for the ios-release-main.yml workflow by replacing or augmenting
the "on: push/branches: [main]" trigger with a more selective trigger such as
"push: tags: ['v*']" or "release" or "workflow_dispatch", and optionally add
"paths:" filters to exclude doc/backend-only changes — update the top-level on:
block to use the chosen trigger(s) so macOS runners and TestFlight submissions
only run for intentional releases or tags.

---

Nitpick comments:
In @.github/workflows/ios-release-main.yml:
- Around line 27-31: Replace the eas-version: latest setting in the step that
uses expo/expo-github-action@v8 with a pinned, known-good EAS CLI version (for
example eas-version: 16.x.x) so builds don't silently change; update the same
eas-version pin in the corresponding dev workflow's expo/expo-github-action@v8
step as well and commit the changed version string rather than leaving it as
"latest".
- Around line 11-15: The workflow lacks an explicit least-privilege permissions
block; add a top-level permissions: entry for this workflow that scopes
GITHUB_TOKEN to only what the build-and-submit job needs (e.g. set contents:
read and artifacts: write and packages: write), and if your submission step uses
OIDC include id-token: write; add this permissions block at the top of the
workflow YAML so the build-and-submit job (name "Build and submit iOS") uses the
restricted token and adjust scopes if any steps require id-token or additional
access.

🪄 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: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 038fb370-cc04-4f3e-923c-c31301673193

📥 Commits

Reviewing files that changed from the base of the PR and between 23fdc62 and d5a7d80.

📒 Files selected for processing (2)

• .github/workflows/ios-release-dev.yml
• .github/workflows/ios-release-main.yml