docs: add introduction page for Capgo Build + explain what gets sent to Capgo build #434
Conversation
📝 WalkthroughWalkthroughAdded new Capgo Build documentation and expanded the getting-started guide, describing service features, supported platforms, build flow, security model, pricing, upload rules, and updated build commands and responsibilities. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
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: 2
🤖 Fix all issues with AI agents
In `@src/content/docs/docs/cli/cloud-build/index.mdx`:
- Around line 77-83: Update the wording in the sentence that currently reads
"Only the platform-specific native code is uploaded." to match the specificity
of the earlier bullet ("native platform folder + native dependencies") — replace
"native code" with "native platform folder and native dependencies" (or
equivalent phrasing) so it clearly conveys both platform files and native
dependencies are uploaded.
- Around line 87-92: The "Capgo Build is designed with zero credential storage"
paragraph and its bullet points contain absolute claims that conflict with
mention of "optional log storage"; verify the product behavior and then update
the text in src/content/docs/docs/cli/cloud-build/index.mdx (the header sentence
and bullets) to remove absolutes like "never" or explicitly state exceptions:
indicate that runtime-only credentials remain in-memory unless a user enables
optional log/audit storage, describe where optional logs are stored, list
configurable retention periods and default retention, and reference any
compliance certifications (e.g., SOC2, ISO27001) that apply; also add a short
note pointing to the audit/logging settings page or CLI flag so users can opt
into/disable log storage.
🧹 Nitpick comments (1)
src/content/docs/docs/cli/cloud-build/index.mdx (1)
17-18: Avoid hard‑coding specific hardware models or fixed multipliers.Line 17 and Line 100-101 can become stale quickly. Consider using generic wording and pointing to pricing for the current multiplier.
♻️ Suggested wording update
- - **iOS builds** run on dedicated Apple Silicon (Mac Mini M4) machines + - **iOS builds** run on dedicated Apple Silicon macOS machines ... - - iOS builds run on Mac Mini M4 (2x cost multiplier due to hardware costs) + - iOS builds run on Apple Silicon macOS machines (see pricing for the current multiplier)Also applies to: 100-101
|
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/content/docs/docs/cli/cloud-build/getting-started.mdx (1)
231-241: Update "Multi-Platform Builds" section to document the--platform bothshortcut.The CLI supports
--platform both(confirmed in the reference docs), which is used in your CI/CD example at line 239. However, the "Multi-Platform Builds" section (lines 257-269) only shows the two-command approach without mentioning that--platform bothis a simpler alternative. Either add a note explaining both approaches or recommend the single-command method with--platform bothas the primary approach for building both platforms.
♻️ Duplicate comments (2)
src/content/docs/docs/cli/cloud-build/index.mdx (2)
73-83: Minor wording inconsistency remains.Line 77 specifies "native platform folder + native dependencies" while Line 83 uses the broader term "platform-specific native code." While the author indicated this was fixed, the phrasing still differs slightly. Consider aligning Line 83 more explicitly:
✍️ Suggested alignment
-Your source code stays on your machine. Only the platform-specific native code is uploaded. +Your web source code stays on your machine. Only the native platform folder and required native dependencies are uploaded.
85-92: Verify "no log storage" claim against actual product capabilities.Line 91 states build logs are "never stored on Capgo servers." A past review identified that Capgo's blog mentions "optional log storage for debugging and audit trails," which would contradict this claim. If optional log storage exists as a feature, the documentation should acknowledge it:
✍️ Suggested refinement if optional logging exists
-- **No log storage** - Build logs stream to your terminal only, never stored on Capgo servers +- **No persistent log storage by default** - Build logs stream to your terminal in real-time and are not retained unless you enable optional audit logging#!/bin/bash # Search for any references to optional log storage or audit features in the codebase rg -i "optional.*log|log.*storage|audit.*log|log.*retention" --type md --type mdx -C 2
WcaleNieWolny
changed the title
Changes
Motivation
Martin asked me to improve the docs for Capgo Build
Business impact
Medium - no one will buy Capgo Build if they do not understand what it is. This introduction fixes that by explaining what Capgo Build is and why to use it.
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.