I don't quite understand everything that's going on here, but this
will get main deployable again.
Summary: the production Docker image build does not put a prebuilt
binary for the sqlite3 package into the image, ever since I added
sqlite3@^5.1.5 as an explicit dependency in #488. I don't know why.
The package was already being installed (as a dependency of
fastify-sqlite) but adding the explicit dependency somehow changed
how it gets installed.
Upping the dependency to 5.1.7 fixes the problem. It causes 5.1.5 to
be installed within node_modules/fastify-sqlite/node_modules in the
prod image, with the prebuilt binary present. (5.1.7 is not installed
in the prod image at all, as I'd expect, since it's under
devDependencies.)
I'm also adding --frozen-lockfile to the yarn invocations in the
Dockerfile; I don't think they're strictly necessary (and they're
definitely not necessary to fix this), but that should eliminate one
other possible source of confusion/problems, especially while
debugging weird issues like this.
Test Plan
Run the server with yarn dev; make test requests and ensure they succeed.
Run:
docker build -t incentives-api:latest .
docker run --rm -it -p 8080:8080 incentives-api:latest
Make sure the server starts up and can serve requests
Description
I don't quite understand everything that's going on here, but this will get main deployable again.
Summary: the production Docker image build does not put a prebuilt binary for the
sqlite3
package into the image, ever since I addedsqlite3@^5.1.5
as an explicit dependency in #488. I don't know why. The package was already being installed (as a dependency offastify-sqlite
) but adding the explicit dependency somehow changed how it gets installed.Upping the dependency to 5.1.7 fixes the problem. It causes 5.1.5 to be installed within
node_modules/fastify-sqlite/node_modules
in the prod image, with the prebuilt binary present. (5.1.7 is not installed in the prod image at all, as I'd expect, since it's underdevDependencies
.)I'm also adding
--frozen-lockfile
to the yarn invocations in the Dockerfile; I don't think they're strictly necessary (and they're definitely not necessary to fix this), but that should eliminate one other possible source of confusion/problems, especially while debugging weird issues like this.Test Plan
Run the server with
yarn dev
; make test requests and ensure they succeed.Run:
docker build -t incentives-api:latest .
docker run --rm -it -p 8080:8080 incentives-api:latest