|
22 | 22 | - Use Tailwind CSS classes instead of inline style objects for new markup |
23 | 23 | - VSCode CSS variables must be added to webview-ui/src/index.css before using them in Tailwind classes |
24 | 24 | - Example: `<div className="text-md text-vscode-descriptionForeground mb-2" />` instead of style objects |
| 25 | + |
| 26 | +4. Marketing Site (web-roo-code) Deployment Quality Gates: |
| 27 | + |
| 28 | + - The marketing site deployment workflows (`.github/workflows/website-deploy.yml`, `.github/workflows/website-preview.yml`) must include quality checks before deploying to Vercel |
| 29 | + - When modifying these workflows, ensure the following checks run before deployment: |
| 30 | + - Linting: `pnpm --filter @roo-code/web-roo-code lint` |
| 31 | + - Type checking: `pnpm --filter @roo-code/web-roo-code check-types` |
| 32 | + - Build validation: `pnpm --filter @roo-code/web-roo-code build` |
| 33 | + - Deployment workflows should either: |
| 34 | + - Add a `needs:` dependency on the `code-qa` workflow (for PR-based deployments), OR |
| 35 | + - Include a dedicated `quality-checks` job that runs before the `deploy`/`preview` jobs |
| 36 | + - For PR-based preview deployments (`website-preview.yml`): |
| 37 | + - The quality checks job should be a required status check in GitHub branch protection |
| 38 | + - This prevents merging PRs with broken previews or failed quality checks |
| 39 | + - Ensures reviewers only see working previews |
| 40 | + - Deployment concurrency controls: |
| 41 | + - Add `concurrency` group to prevent multiple deployments from running simultaneously |
| 42 | + - Set `cancel-in-progress: true` to cancel older deployments when new ones start |
| 43 | + - Prevents race conditions where older commits could overwrite newer deployments |
| 44 | + - Vercel CLI version stability: |
| 45 | + - Use `vercel@latest` instead of `vercel@canary` for stable, production deployments |
| 46 | + - Canary releases are unstable and could introduce breaking changes unexpectedly |
| 47 | + - Pin to specific versions for critical production workflows when possible |
| 48 | + - Never deploy broken code to production - quality gates prevent deployment of code that fails linting, type-checking, or build steps |
0 commit comments