Replacing the previous git checkout approach: using DIESEL_CONFIG_FILE
pointing to /dev/null gives diesel an empty config with no [print_schema]
section, so schema.rs is never written. This is cleaner than restoring
the file after the fact, which would silently hide genuine schema drift.
Two bugs exposed by the integration test workflow:
1. MySQL migration 2022-07-27: groups_users and collections_groups used
UNIQUE instead of PRIMARY KEY. Diesel requires primary keys on all
tables for schema introspection (print-schema). PostgreSQL and SQLite
migrations already used PRIMARY KEY correctly.
2. diesel.toml has [print_schema] configured, so \`diesel migration run\`
rewrites src/db/schema.rs with backend-specific types after running.
This corrupted the checked-in schema before cargo test could compile,
causing E0277 CompatibleType errors for every query. Fix by restoring
the file immediately after each migration run.
MySQL client libraries resolve 'localhost' to a Unix socket path
(/run/mysqld/mysqld.sock), which does not exist in the containerized
service. Use 127.0.0.1 to force a TCP connection.
Two jobs - one per db - each spinning up a service container:
1. diesel migration run --migration-dir migrations/<db>
Verifies every migration applies cleanly to a fresh instance.
This is the primary gap: a broken migration would otherwise only
surface on production deployment.
2. cargo test --features <db> with DATABASE_URL set
Builds and runs the test suite against the live engine. Existing
tests are unit-level (no DB access), but DATABASE_URL is wired in
so any future integration tests work without further infrastructure
changes.
Service containers: postgres:16, mysql:8.4 (utf8mb4).
diesel CLI binary is cached keyed on Cargo.lock hash to avoid
recompiling it on every run.
Triggers on the same path set as build.yml (src/**, migrations/**,
Cargo.*, rust-toolchain.toml).
TriplEight