doc: add tutorial for releasing sdks #10745
Conversation
📝 WalkthroughWalkthroughA new documentation file Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✨ 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 |
Security Scan Results for PRDocker Image Scan Results
Source Code Scan Results🎉 No vulnerabilities found! |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (5)
docs/tutorials/release-sdks.md (5)
44-56: SSH configuration mismatch between documentation and best practice.Line 52 mounts
~/.ssh:/root/.sshdirectly. While this works, the guide should note:
- Ensure SSH keys have restrictive permissions (600) on the host.
- Consider using
ssh-agentforwarding instead for ephemeral access (more secure in containerized environments).- Document that SSH keys must be added to the GitHub account on the host machine before building the container.
Also, clarify whether this mount is necessary if using GitHub CLI with a token (as mentioned in line 37), or if it's only needed for Git SSH operations.
76-91: Interactive prompts lack error handling and retry guidance.Lines 87-91 describe the interactive prompts but don't address:
- What happens if invalid input is provided? Does the script retry, exit, or use defaults?
- Can prompts be bypassed with CLI flags? (e.g.,
--platform=client --sdks=dart --version=1.8.x)- What does
*mean for SDKs? Is it documented elsewhere?Consider adding:
- Example interaction showing valid/invalid responses and outcomes
- Exit codes or error messages the user might encounter
- Whether dry-run is recommended before actual execution
105-110: Pull Request Summary example uses placeholder URLs.The example PR URLs (lines 107-109) use placeholder PR numbers (e.g.,
#123). For clarity, document:
- Whether PR numbers are predictable or random.
- Link to an example of a real SDK release PR for reference.
- Note that PR creators should review and address any CI failures or review feedback.
152-158: Configuration file references lack direct links.The reference section (lines 152-158) lists critical configuration files but doesn't provide direct links to them in the repository. Consider:
- Adding GitHub links to each file for quick navigation.
- Noting the branch/version (e.g., "in the
1.8.xbranch" or "in the main branch") if files differ across versions.- Briefly documenting the structure of
app/config/platforms.php(e.g., what fields are required for a new SDK).
160-174: Troubleshootin 8000 g section could include log locations.Lines 160-174 cover common issues but don't mention where to find relevant logs:
- Docker logs:
docker compose logs appwrite- Script output or error messages
- GitHub CLI debug output (e.g.,
gh --debug)Add guidance like:
If the script fails, check logs with:
docker compose logs appwrite -fThis will help users debug issues faster.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/tutorials/release-sdks.md(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (17)
- GitHub Check: E2E Service Test (VCS)
- GitHub Check: E2E Service Test (Tokens)
- GitHub Check: E2E Service Test (Sites)
- GitHub Check: E2E Service Test (Databases/TablesDB)
- GitHub Check: E2E Service Test (FunctionsSchedule)
- GitHub Check: E2E Service Test (Teams)
- GitHub Check: E2E Service Test (Health)
- GitHub Check: E2E Service Test (Functions)
- GitHub Check: E2E Service Test (Avatars)
- GitHub Check: E2E Service Test (Projects)
- GitHub Check: E2E Service Test (Console)
- GitHub Check: E2E Service Test (Databases/Legacy)
- GitHub Check: E2E Service Test (Account)
- GitHub Check: E2E Service Test (Site Screenshots)
- GitHub Check: E2E Service Test (Dev Keys)
- GitHub Check: E2E General Test
- GitHub Check: Unit Test
🔇 Additional comments (1)
docs/tutorials/release-sdks.md (1)
1-9: Verify external links and document context clearly.Lines 1-9 reference external documents:
- CODE_OF_CONDUCT:
https://github.com/appwrite/.github/blob/main/CODE_OF_CONDUCT.md- CONTRIBUTING:
https://github.com/appwrite/appwrite/blob/master/CONTRIBUTING.mdPlease verify these links are current and accessible. Also note:
- Are these links maintained by the Appwrite team?
- Do they cover SDK release-specific contribution guidance, or is this guide meant to supplement them?
| ARG GH_TOKEN | ||
| ENV GH_TOKEN=your_github_token_here | ||
| RUN git config --global user.email "your-email@example.com" | ||
| RUN apk add --update --no-cache openssh-client github-cli | ||
| ``` | ||
|
|
||
| Replace: | ||
| - `your_github_token_here` with your GitHub personal access token (with appropriate permissions) | ||
| - `your-email@example.com` with your Git email address |
There was a problem hiding this comment.
Lines 34-35 show a Dockerfile with a GitHub token in plaintext (ENV GH_TOKEN=your_github_token_here). This is a significant security risk and anti-pattern:
- Secrets should never be in the Dockerfile — they'll be baked into the image layer history.
- Credentials exposed in documentation — even as placeholders, this pattern teaches bad practices.
- Tokens and email visible to all with image access — anyone with access to the Docker image can extract these values.
Use Docker build secrets or pass credentials at runtime instead. Here's a better approach:
# Don't hardcode — pass at runtime or use Docker build secrets
RUN apk add --update --no-cache openssh-client github-cli
# Configure Git at runtime or via environment variableThen document how to pass credentials securely:
docker compose exec appwrite sh -c 'git config --global user.email "your-email@example.com" && gh auth login'Or leverage Docker build secrets (BuildKit):
RUN --mount=type=secret,id=gh_token \
gh auth login --with-token < /run/secrets/gh_token🤖 Prompt for AI Agents
In docs/tutorials/release-sdks.md around lines 34 to 42, the Dockerfile snippet
hardcodes GH_TOKEN and an email (ENV GH_TOKEN=your_github_token_here and git
config --global user.email ...), which is insecure; remove the ARG/ENV token and
the hardcoded email from the example and replace with guidance to pass
credentials securely at build or runtime (e.g., use Docker BuildKit secrets or
pass tokens via runtime environment/interactive auth), update the doc to show
the secure workflow steps (how to provide a secret to the build using build
secrets and how to run a container and perform git/gh auth at runtime) and
include example commands/instructions for both approaches (BuildKit secret usage
and runtime gh auth/docker-compose exec) instead of embedding credentials in the
Dockerfile.
✨ Benchmark results
⚡ Benchmark Comparison
|
No description provided.