Run migrations on deploy

e3eb2ce · Gabriel Morell · 2026-08-11 17:06

3 files +22 -1
Message
{commit_body(@commit)}

Files changed

modified Dockerfile
+3 −1
@@ -31,4 +31,6 @@ EXPOSE 4002
31 31 EXPOSE 4001
32 32 WORKDIR /opt/app
33 33 COPY --from=0 /opt/release .
34 −CMD exec /opt/app/bin/start_server start
34 +COPY rel/entrypoint.sh /opt/app/entrypoint.sh
35 +RUN chmod +x /opt/app/entrypoint.sh
36 +CMD ["/opt/app/entrypoint.sh"]
added rel/entrypoint.sh
+19 −0
@@ -0,0 +1,19 @@
1 +#!/bin/sh
2 +#
3 +# Run pending migrations, then start the server.
4 +#
5 +# Both repos live in one database and share one schema_migrations table, so
6 +# this is the same work `mix ecto.migrate` does at the umbrella root -- each
7 +# migrator only runs the files its own app ships.
8 +#
9 +# set -e matters: if a migration fails the container exits non-zero and never
10 +# serves, so Kubernetes keeps the previous pod up rather than rolling out one
11 +# running new code against an old schema. Ecto takes an advisory lock per repo,
12 +# so the overlap during a rolling update is safe.
13 +set -e
14 +
15 +echo "==> apollos-crib: migrating"
16 +/opt/app/bin/start_server eval 'RoomSanctum.Release.migrate(); RoomHermes.Release.migrate()'
17 +
18 +echo "==> apollos-crib: starting"
19 +exec /opt/app/bin/start_server start

Parents: 5db6307