With a vanilla Rails 8, kamal initial kamal deploy fails due to schema creation

[justin808]

This is specific to the Rails 8 defaults.

Because db:prepare is called in the entry-point, that runs on the first deployment, the first deploy times out.

Maybe the first deployment needs a longer deploy_timeout?

Or one can run kamal deploy twice initially.

Here are the logs, which are a bit confusing on what caused the failure, as there is no specific error.

  INFO [cb1d3e98] Running docker exec kamal-proxy kamal-proxy deploy rails_kamal_demo-web --target="451c0be93e76:80" --host="kamal.shakacode.com" --tls --deploy-timeout="30s" --drain-timeout="30s" --buffer-requests --buffer-responses --log-request-header="Cache-Control" --log-request-header="Last-Modified" --log-request-header="User-Agent" on 35.223.120.113
 ERROR Failed to boot web on 35.223.120.113
  INFO First web container is unhealthy on 35.223.120.113, not booting any other roles
  INFO [c4a48207] Running docker container ls --all --filter name=^rails_kamal_demo-web-0e656af7b0fe2b0412ea4e40ea8fb57b05b615ec$ --quiet | xargs docker logs --timestamps 2>&1 on 35.223.120.113
  INFO [c4a48207] Finished in 2.489 seconds with exit status 0 (successful).
 ERROR 2025-01-06T21:49:34.454491745Z   SQL (7.4ms)  CREATE EXTENSION IF NOT EXISTS "plpgsql" SCHEMA pg_catalog
2025-01-06T21:49:34.454568171Z    (4.6ms)  DROP TABLE IF EXISTS "posts" CASCADE
2025-01-06T21:49:34.454578100Z    (52.3ms)  CREATE TABLE "posts" ("id" bigserial primary key, "title" character varying, "body" text, "created_at" timestamp(6) NOT NULL, "updated_at" timestamp(6) NOT NULL)
2025-01-06T21:49:34.454631091Z    (2.9ms)  DROP TABLE IF EXISTS "solid_queue_processes" CASCADE
2025-01-06T21:49:34.454637853Z    (14.1ms)  CREATE TABLE "solid_queue_processes" ("id" bigserial primary key, "created_at" timestamp(6) NOT NULL, "updated_at" timestamp(6) NOT NULL)
2025-01-06T21:49:34.454651934Z    (16.6ms)  CREATE TABLE "schema_migrations" ("version" character varying NOT NULL PRIMARY KEY)
2025-01-06T21:49:34.454657936Z   ActiveRecord::SchemaMigration Load (13.7ms)  SELECT "schema_migrations"."version" FROM "schema_migrations" ORDER BY "schema_migrations"."version" ASC
2025-01-06T21:49:34.454663947Z    (6.8ms)  INSERT INTO "schema_migrations" (version) VALUES (20241215221345)
2025-01-06T21:49:34.454669276Z    (3.7ms)  INSERT INTO "schema_migrations" (version) VALUES

and

  INFO [73debe2f] Running docker container ls --all --filter name=^rails_kamal_demo-web-0e656af7b0fe2b0412ea4e40ea8fb57b05b615ec$ --quiet | xargs docker inspect --format '{{json .State.Health}}' on 35.223.120.113
  INFO [73debe2f] Finished in 2.755 seconds with exit status 0 (successful).
 ERROR null
  INFO [86a67b24] Running docker container ls --all --filter name=^rails_kamal_demo-web-0e656af7b0fe2b0412ea4e40ea8fb57b05b615ec$ --quiet | xargs docker stop on 35.223.120.113
  INFO [86a67b24] Finished in 4.310 seconds with exit status 0 (successful).
  Finished all in 267.2 seconds
Releasing the deploy lock...
  Finished all in 275.3 seconds
  ERROR (SSHKit::Command::Failed): Exception while executing on host 35.223.120.113: docker exit status: 1
docker stdout: Nothing written
docker stderr: Error: target failed to become healthy within configured timeout (30s)

[djmb]

Maybe we should default Rails to running db:prepare in a pre-deploy hook. The container will have been pulled to the host at that point so something like kamal app exec -p bin/rails db:prepare might work.

We'd need to make sure it was running the correct version and possibly add the option to copy any secrets first (see #1223 (comment))