f4248bf20df5286e428bde4b2787580d2b2f494c
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 |
af110633c1 |
refactor: detach yarn prisma generate from yarn-install action (#26382)
* refactor: detach yarn prisma generate from yarn-install action Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * fix: add run-prisma-generate input for backward compatibility The yarn-install action now has a run-prisma-generate input that defaults to true for backward compatibility. This ensures CI works correctly since workflow files are pulled from the base branch (main) while actions are pulled from the PR branch. Workflows that have explicit yarn prisma generate steps now set run-prisma-generate: false to avoid running it twice after merge. Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * refactor: completely remove prisma generate from yarn-install action Remove all prisma-related code from the yarn-install action: - Remove the run-prisma-generate input parameter - Remove the Generate Prisma client step Remove explicit yarn prisma generate steps from all workflow files. Prisma generation is now handled by the postinstall script in package.json which runs 'turbo run post-install' after yarn install. This triggers @calcom/prisma#post-install which runs 'prisma generate && prisma format'. This makes the yarn-install action have no knowledge of Prisma at all, as requested. Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * fix: add generic post-install step to ensure generated files are up-to-date When all caches are hit, yarn install completes quickly without running the postinstall script. This means generated files (like Prisma types) may not be created. Add a generic 'turbo run post-install' step that runs after yarn install to ensure all post-install tasks complete regardless of cache state. This keeps the action from having Prisma-specific knowledge while ensuring the post-install pipeline runs. Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * refactor: remove post-install step from yarn-install action Remove the turbo run post-install step as requested. The yarn-install action now only handles yarn install with caching, with no knowledge of post-install tasks or Prisma generation. Let CI show what fails without explicit post-install handling. Co-Authored-By: keith@cal.com <keithwillcode@gmail.com> * Add back Prisma schema loaded from schema.prisma ✔ Generated Prisma Client (6.16.1) to ./generated/prisma in 442ms ✔ Generated Zod Prisma Types to ./zod in 1.43s ✔ Generated Kysely types (2.2.0) to ./../kysely in 271ms ✔ Generated Prisma Enum Generator to ./enums/index.ts in 176ms where needed * Adding Prisma schema loaded from schema.prisma ✔ Generated Prisma Client (6.16.1) to ./generated/prisma in 451ms ✔ Generated Zod Prisma Types to ./zod in 1.40s ✔ Generated Kysely types (2.2.0) to ./../kysely in 271ms ✔ Generated Prisma Enum Generator to ./enums/index.ts in 205ms where needed for E2E --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> |
||
|
|
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> |
||
|
|
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> |
||
|
|
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> |