dotnet ef migrations: EF Core Migrations in CI
dotnet ef migrations manages EF Core schema migrations, and dotnet ef database update applies them to a database.
EF migrations in CI mean applying or bundling schema changes during deploy. The trick is pointing the tool at the right project and DbContext.
What it does
dotnet ef is a local tool that drives EF Core. migrations add scaffolds a migration, migrations script emits idempotent SQL, database update applies pending migrations, and migrations bundle produces a self-contained executable to apply them at deploy time.
Common usage
dotnet tool restore
dotnet ef migrations script -i -o migrate.sql \
--project src/Data --startup-project src/Api
dotnet ef database update --project src/Data --startup-project src/Api
dotnet ef migrations bundle --self-contained -r linux-x64 -o efbundleOptions
| Flag | What it does |
|---|---|
| --project <path> | Project containing the DbContext and migrations |
| --startup-project <path> | Project with the app host/config used to build the context |
| -c, --context <name> | DbContext to use when more than one exists |
| -i, --idempotent (script) | Generate SQL safe to run against any starting state |
| -o, --output <file> | Output path for script or bundle |
| --connection <string> | Override the connection string |
In CI
Prefer migrations script -i or migrations bundle over running database update directly from the build runner; an idempotent SQL script or a bundle decouples schema changes from a live build connection. Restore the tool first with dotnet tool restore. When the context lives in a class library, you must pass both --project and --startup-project.
Common errors in CI
"Unable to create a 'DbContext' of type ..." means the startup project could not be built or its config (connection string) is missing; set --startup-project and the connection. "No project was found. Change the current working directory or use the --project option" speaks for itself. "Could not execute because the specified command or file was not found: dotnet ef" means you skipped dotnet tool restore.
Using this in CI
- Set the shell explicitly and enable
set -euo pipefail; the default runner shell does not stop on the first error inside a multi-line block. - Pin the tool version. An unpinned build tool turns a runner image update into a build break on unchanged code.
- Prefer non-interactive and batch flags. Progress output designed for a terminal bloats CI logs and can hang without a TTY.
- Write machine-readable output (JSON, JUnit) to a file and upload it as an artifact, so a failure is diagnosable without re-running the job.