Saadi Myftija
255a73a2fe
This PR adds support for CLI deployments using the native build server. **Background** The deployment command currently does the following: - bundles the code - submits the build context to our external build provider and waits for the build - triggers deployment state transitions using the platform API Upstream build provider outages cause issue with deployments, potentially blocking deployments entirely. We recently introduced the `--force-local-build` flag as a fallback to enable deployment without a dependency on the upstream build provider, though it requires users to have docker in their systems. This PR continues that work by providing a remote build path which uses our own build server and does not rely on the external provider. **Changes in this PR** Introduced the new `--native-build-server` flag, which does the following: - scans all files relevant for the Trigger deployment and evaluates ignore rules - packages it up in an archive and uploads it as a deployment artifact - queues the deployment and triggers the build - streams logs from the build server This no longer relies on external build services. Also deployment state transitions happen on the server-side, giving us more flexibility to evolve the flow and schemas of related deployment API endpoints. In general it gives us better control of the whole build and deployment process. This path will eventually become the default. The `--detach` flag is also new, allowing to trigger deployments without waiting for the result. The deployment artifacts are uploaded via pre-signed URLs to avoid unnecessary load on the platform. The new `/artifacts` endpoint generates the pre-signed URLs; size limits are enforced on s3. This endpoint is deliberately generic, we could extend it in the future to upload other artifacts client-side in a similar way, e.g., large payload packets.
@trigger.dev/database
This is the internal database package for the Trigger.dev project. It exports a generated prisma client that can be instantiated with a connection string.
How to switch branches when you've done migrations
Sometimes you've applied migrations and then want to switch branches without wiping out your local database.
To do this you can run the following command:
DB_VOLUME=database-data-alt pnpm run docker
This will switch to the alt volume for your local database. This database will be blank if you haven't switched to this volume before, so you'll need to follow the normal steps (in the Contributing guide) to get setup, e.g. apply migrations and seed.
To switch back to the original volume, run the following command:
pnpm run docker
How to add a new index on a large table
- Modify the Prisma.schema with a single index change (no other changes, just one index at a time)
- Create a Prisma migration using
cd internal-packages/database && pnpm run db:migrate:dev:create - Modify the SQL file: add IF NOT EXISTS to it and CONCURRENTLY:
CREATE INDEX CONCURRENTLY IF NOT EXISTS "JobRun_eventId_idx" ON "JobRun" ("eventId");
- Don’t apply the Prisma migration locally yet. This is a good opportunity to test the flow.
- Manually apply the index to your database, by running the index command.
- Then locally run
pnpm run db:migrate:deploy
Before deploying
Run the index creation before deploying
CREATE INDEX CONCURRENTLY IF NOT EXISTS "JobRun_eventId_idx" ON "JobRun" ("eventId");
These commands are useful:
-- creates an index safely, this can take a long time (2 mins maybe)
CREATE INDEX CONCURRENTLY IF NOT EXISTS "JobRun_eventId_idx" ON "JobRun" ("eventId");
-- checks the status of an index
SELECT * FROM pg_stat_progress_create_index WHERE relid = '"JobRun"'::regclass;
-- checks if the index is there
SELECT * FROM pg_indexes WHERE tablename = 'JobRun' AND indexname = 'JobRun_eventId_idx';
Now, when you deploy and prisma runs the migration, it will skip the index creation because it already exists. If you don't do this, there will be pain.