`docker-compose up` fails to run migrations

[bryanburgers]

When I do a fresh clone of the crates.io repo, and then run docker-compose up, the backend fails to come up and instead gets stuck in a loop:

...
backend_1   | Read-only file system (os error 30)
backend_1   | Migrations failed, retrying in 5 seconds...
backend_1   | Read-only file system (os error 30)
backend_1   | Migrations failed, retrying in 5 seconds...
backend_1   | Read-only file system (os error 30)
backend_1   | Migrations failed, retrying in 5 seconds...
...

For new contributors, this should not happen and should instead come up without errors to ease the path to start working on the project.

---

From what I've been able to tell so far, diesel migration run is succeeding in the sense that it is running all of the migrations. (It lists the last migration that it is supposed to run, and I manually verified that that migration succeeded.)

Where it fails is that diesel migration run is trying to create src/schema.rs.orig on the source volume that is mounted as read-only, so when that fails it returns a non-zero exit code.

Two potential solutions I see:

1. Mount the source directory as read-write instead of read-only. This would be a very easy fix, and allow diesel migration run to write that file, and that file may be valuable (I'm not sure, I haven't worked with diesel before.)
2. Determine what we need to do to make diesel migration run not write that file. Do we need to re-sync src/schema.rs? Is there an option in diesel that prevents creating that file?

[sgrif]

Just to clarify, that file would be getting created by patch, not by diesel. My understanding is that it would only get created if applying schema.patch to the generated schema.rs failed. That said, I can't reproduce the patch failing to apply (attempted by running diesel database drop && diesel database setup locally). It might be a difference between the version of patch on my machine, and whatever is on the OS docker is using.

Since we're not expecting the source directory to change in docker, we could do diesel migration run --locked-schema instead, which tells Diesel to just error if the generated schema file differs from what's on disk. This still needs to write to the file system (patch doesn't support reading from stdin or outputting to stdout), but it'll operate on a tempfile instead of the schema.rs which should be writable

[bryanburgers]

Yes! --locked-schema was exactly what I was looking for.