Fix dev image: seed the default admin and pre-build assets

[junkerderprovinz]

Summary

#230 reports that the dev setup produces a running server with no admin account to log in with.

What this changes

One line in Dockerfile.dev's ENTRYPOINT (used by compose.dev.yml's app service):

mix ecto.migrate -> mix ecto.setup

ecto.setup is the alias already defined in mix.exs (ecto.create + ecto.migrate + run priv/repo/seeds.exs), so the seeds actually run and the default admin@claper.co account gets created.

Verification

Ran the dev image against a Postgres 15 container using the repo's own .env.sample values, on a fresh clone with an empty _build:

Created admin role
Created default admin user:
  Email: admin@claper.co
Global settings seeded
[info] Running ClaperWeb.Endpoint with cowboy 2.13.0 at 0.0.0.0:4000 (http)

Then logged in as admin@claper.co and confirmed /admin returns 200, while the same request logged out redirects to /users/log_in. So the admin role assignment works too, not just the user row.

Assets are left to the dev watchers configured in config/dev.exs, which build all four outputs (app.css, admin.css, app.js, custom.css) without any help from the entrypoint.

Notes

• Only fixes a fresh database. Seeds only run when the users table is empty. If you already have a claper-db volume from hitting this bug, run docker compose -f compose.dev.yml down -v first, or mix ecto.reset inside the container.
• Needs a rebuild to take effect, since the entrypoint is baked into the image: docker compose -f compose.dev.yml up --build.
• Seed failures now block boot, since they sit in the same && chain, where a migrate-only entrypoint could not be taken down by a seed bug.
• Not addressed: compose.dev.yml's app service has depends_on: db without waiting on the db healthcheck, so a cold start can still race Postgres accepting connections. Pre-existing, out of scope here.

Fixes #230

[alxlion]

Thanks for the PR.

The pre-build commands aren’t needed: dev.exs already runs esbuild, Tailwind, and Sass as watchers through mix phx.server, including live reload. Adding them to the entrypoint just builds everything twice and slows cold starts.
The useful change is mix ecto.migrate → mix ecto.setup, which fixes the missing seeded admin.

[alxlion]

Suggested change

	ENTRYPOINT ["bash", "-c", "mix deps.get && mix ecto.setup && cd assets && npm i && cd .. && mix esbuild default && mix tailwind default && mix tailwind admin && mix sass default && mix phx.server"]
	ENTRYPOINT ["bash", "-c", "mix deps.get && mix ecto.setup && cd assets && npm i && cd .. && mix phx.server"]

[junkerderprovinz]

Thanks @alxlion, you're right. Pushed, the PR is now just mix ecto.migrate -> mix ecto.setup.

I checked the watcher claim before dropping the pre-build and it holds: config/dev.exs starts all four (esbuild, tailwind default, tailwind_admin, sass) through install_and_run, so phx.server builds everything itself and the pre-build was just repeating that work on every start.

Measured it on a fresh clone with an empty _build:

• Cold first boot: endpoint listening at 15:07:54.042, all four outputs built at 15:07:58.94. Roughly 5s, and essentially all of it is the standalone binary downloads (tailwind's is 120 MB).
• Warm restart: endpoint at 15:10:19.532, builds done at 15:10:19.776. 244 ms, no downloads, and the previous run's CSS is still on disk.

So the race I originally hit is real, but far smaller than my description made it sound, and it only happens on the first run of a fresh checkout. The 45-60s I saw was the download on a slower line, which pre-building didn't avoid either. It just moved it ahead of the listener and added a duplicate build to every boot after that.

If you ever want that first boot tightened, the download-only version would be mix tailwind.install --if-missing && mix sass.install --if-missing && mix esbuild.install --if-missing, which skips the second build and is a no-op once the binaries are cached. Happy to leave it out though, live reload covers it fine.

Verified on the simplified branch: seeds run, admin@claper.co logs in, /admin returns 200 when logged in and redirects to /users/log_in when logged out, and all four asset files are built and served by the watchers alone.