16f6099e46ef92530e7561fbcdc8287f2df489dd
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  Keith WilliamsandDevin AI
|
16f6099e46 |
ci: simplify DB cache key and skip yarn-install on cache hit (#26344)
* ci: skip yarn-install in setup-db when DB cache exists Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * ci: skip entire setup-db job when DB cache exists This saves ~35-40s per workflow run by: 1. Adding DB cache lookup to prepare job (lookup-only mode) 2. Skipping the entire setup-db job when cache exists (avoids postgres container startup) 3. Keeping the yarn-install skip in setup-db.yml as a fallback Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * ci: simplify DB cache key and skip yarn-install on cache hit - Remove commit SHA and PR number from cache key for better reuse - Cache key now only depends on prisma schema/migrations hash - Skip yarn-install in setup-db when DB cache exists (saves ~17s) - Revert changes to pr.yml required job logic Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * ci: move DB cache lookup to prepare step and skip cache-db on hit - Move cache lookup to pr.yml prepare step for early detection - Pass db-cache-hit output to setup-db.yml as input - Skip yarn-install and cache-db action when cache exists - setup-db job still runs and reports success (no required job changes) Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * ci: skip container initialization when DB cache exists - Rename setup-db to setup-db-seed (only runs on cache miss) - Add lightweight setup-db wrapper job that always returns success - When cache exists: setup-db-seed is skipped, setup-db returns success - When cache miss: setup-db-seed runs with postgres, setup-db checks result - This avoids postgres container startup (~17-20s) when cache exists Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * ci: add cache-db-key action for consistent cache key generation - Create cache-db-key action to generate DB cache key in one place - Update cache-db action to use cache-db-key for consistency - Update pr.yml prepare step to use cache-db-key for lookup - This ensures the lookup key always matches the actual cache key Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * ci: remove runner.os from cache-db-key Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * ci: simplify setup-db by removing wrapper job - Remove setup-db wrapper job and rename setup-db-seed back to setup-db - setup-db is now skipped when cache exists (no container startup) - Update required check to allow skipped for setup-db when cache hit Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * ci: revert to two-job pattern for setup-db - setup-db-seed: only runs on cache miss (has postgres container) - setup-db: wrapper that always runs and reports success - This ensures downstream jobs (Tests, Production builds) are not skipped - Reverts required check to simple setup-db.result != 'success' Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * ci: single setup-db job with conditional steps on cache hit - Removed two-job pattern (setup-db-seed + wrapper) - Single setup-db job calls setup-db.yml reusable workflow - Pass DB_CACHE_HIT input from prepare job's db-cache-hit output - Skip yarn-install and cache-db steps when cache hit (~17s savings) - Container still starts (will optimize in follow-up) Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> |
||
|
Keith WilliamsandDevin AI
|
2a6a8e635c |
chore: migrate GitHub workflows from Buildjet to Blacksmith (#26247)
* chore: migrate GitHub workflows from Buildjet to Blacksmith - Replace buildjet-*vcpu-ubuntu-2204 runners with blacksmith-*vcpu-ubuntu-2204 - Replace buildjet/cache@v4 with actions/cache@v4 - Replace buildjet/setup-node@v4 with actions/setup-node@v4 - Replace buildjet/cache-delete@v1 with useblacksmith/cache-delete@v1 - Rename delete-buildjet-cache.yml to delete-blacksmith-cache.yml Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * chore: bump Blacksmith runners to Ubuntu 24.04 Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * Reduce 16vcpu to 4vcpu for the API v2 E2E * Remove 8vcpu usage * chore: switch Blacksmith runners to ARM architecture Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * chore: switch Blacksmith runners back to AMD (remove -arm suffix) Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * fix: improve test cleanup to cover all bookings including reassignment-created ones - Changed afterEach cleanup to find all bookings by eventTypeId instead of tracking bookingIds - This ensures bookings created indirectly by managedEventManualReassignment are also cleaned up - Removed problematic prefix-based deleteMany calls that could affect parallel tests - Fixes idempotencyKey collision errors on high-parallelism CI runners Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * fix: improve icons screenshot test stability with deviceScaleFactor and increased threshold Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * fix: cap Playwright workers to 4 to match vCPU allocation on Blacksmith runners Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> |
||
|
Keith WilliamsandDevin AI
|
054a0fa7db |
refactor: Add dedicated setup-db job to eliminate cache race condition (#26171)
* refactor: Add dedicated setup-db job to eliminate cache race condition - Create new setup-db.yml workflow that runs cache-db action - Update pr.yml to add setup-db job that runs before all E2E jobs - Update integration-test, e2e, e2e-api-v2, e2e-app-store, e2e-embed, and e2e-embed-react jobs to depend on setup-db instead of build-api-v1 - Add setup-db to required job needs list and result check This eliminates the race condition where multiple jobs could try to write to the same database cache simultaneously. Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * refactor: Remove DB parts from api-v1-production-build.yml The database setup is now handled by the dedicated setup-db job, so the postgres service and cache-db action are no longer needed in the API v1 build workflow. Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * Apply suggestion from @keithwillcode * Made integration tests dependency consistent * refactor: Remove unnecessary env vars from setup-db.yml Only keep the env vars needed for database setup: - CALENDSO_ENCRYPTION_KEY (for db-seed) - DATABASE_URL / DATABASE_DIRECT_URL (for database connection) - TURBO_TOKEN / TURBO_TEAM (for turbo caching) Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * fix: Add back E2E_TEST_CALCOM_QA_* env vars needed by db-seed These env vars are used by scripts/seed.ts to create the QA user with Google Calendar credentials during database seeding. Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * fix: Restore postgres service and cache-db to api-v1-production-build.yml The API v1 build still needs a database to run properly. Restored the postgres service and cache-db action, and added dependency on setup-db so it waits for the database cache to be created first. Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * E2E for API v2 no longer waiting on API v2 build * Reordering the jobs by dependencies * add GOOGLE_API_CREDENTIALS env var to setup db * Added back all env vars to setup-db * fix: Include commit SHA in cache-db key to invalidate cache on new commits Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * refactor: Strip back setup-db.yml env vars to minimal set needed for db-seed Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> |