Migrate Turbo CI from --target flags to a CI environment

Before Paradime supported multiple Bolt environments, a workspace had a single Bolt connection. Turbo CI runs selected the ci warehouse target by appending --target ci to every dbt™ command in the schedule. With environments, the Turbo CI schedule runs in a dedicated CI environment whose connection already uses the ci target. The environment carries the connection and target, so your commands stay clean and there is nothing to forget when you add a new command to the schedule. Before

schedules:
  - name: turbo ci run
    slug: turbo-ci-run-t1u2v3
    environment: production
    commands:
      - dbt build --select state:modified+ --target ci

After

schedules:
  - name: turbo ci run
    slug: turbo-ci-run-t1u2v3
    environment: tagging-iguana-qhhi5i   # your CI environment's slug
    commands:
      - dbt build --select state:modified+

Step 1: Create the CI environment

Go to Settings > Environments and open the Bolt section.
Click Create environment and name it, for example, ci.

The new environment appears below your default environment with its own slug shown next to the name. You will need this slug for YAML-defined schedules.

Step 2: Add a connection with the ci target

On the new environment, click Add connection.
Use the same warehouse and credentials as your existing Bolt connection (or dedicated CI credentials if you have them).
Set the target name to ci and keep the default schema you used with the old --target ci setup.

Setting the target to ci matters: your generate_schema_name.sql macro keys on target.name == 'ci' to build into the temporary paradime_turbo_ci_pr_ schema. The macro needs no changes. See Configure a custom schema for CI runs.

Step 3: Point the Turbo CI schedule at the environment

UI-managed schedules: open the schedule, go to Schedule settings, and set Environment to the CI environment.
YAML-managed schedules: set environment: to the CI environment’s slug in paradime_schedules.yml. The slug is shown next to the environment name in Settings > Environments.

Step 4: Remove —target ci from the commands

Delete the --target ci flag from every command in the schedule. The environment’s connection now supplies the target, so dbt build --select state:modified+ --target ci becomes dbt build --select state:modified+.

Step 5: Verify with a test pull request

Open a small test pull request so your CI provider triggers the Turbo CI schedule.
In the run details, confirm the run used the CI environment and that models built into a paradime_turbo_ci_pr_ prefixed schema.
Merge or close the test PR.

Migrate incrementally if you prefer: --target ci keeps working as before, and a command-level --target flag simply overrides the connection’s target. Move the schedule to the CI environment first, confirm a green run, then strip the flags.

The same pattern applies beyond CI: any schedule that appends --target flags to select a different warehouse target (for example a staging build) can instead run in its own environment with a dedicated connection.

Turbo CI setup for the full CI configuration, including the schema macro and provider pipelines
Create and manage environments for environment lifecycle and per-environment connections
Configuration reference for the environment field in YAML schedules

​Step 1: Create the CI environment

​Step 2: Add a connection with the ci target

​Step 3: Point the Turbo CI schedule at the environment

​Step 4: Remove —target ci from the commands

​Step 5: Verify with a test pull request

​Related

Step 1: Create the CI environment

Step 2: Add a connection with the ci target

Step 3: Point the Turbo CI schedule at the environment

Step 4: Remove —target ci from the commands

Step 5: Verify with a test pull request

Related