feat(dev): express dependencies better

[miketheman]

Currently, a developer is expected to perform make serve prior to
running make initdb, as the serve command will start all
services expressed in docker-compose.yml.

By using a healthcheck on db that uses a built-in CLI tool to test
for health, and Docker Compose 3.9 Long Syntax for the conditions, we
can now run make initdb in one command, followed by make serve.

This enables pre-build behaviors to establish the postgres and
elasticsearch databases prior to other apps starting.

Refs: https://docs.docker.com/compose/compose-file/#healthcheck
Refs: https://www.postgresql.org/docs/10/app-pg-isready.html
Refs: https://docs.docker.com/compose/compose-file/#long-syntax-1

Signed-off-by: Mike Fiedler [email protected]

[miketheman]

@di This is a pre-step to adding a .gitpod.yml that performs make initdb alone to speed up the dev cycle.

I'd encourage any reviewer to make purge && make initdb && make serve to test this out.

[di]

@miketheman Somewhat related, have you seen #9993? Any thoughts on how that would relate here?

[miketheman]

@di I recall reading that a little while ago, and I think that depending on what it is we're trying to optimize for will change the direction of either this PR or that one.

If the purpose is to minimize the interaction a developer had to take on their initial usage, then that PR is a good idea to pursue, potentially independent of this one.

If we leverage Gitpod as a cloud development platform, then it kind of sidesteps the issue, as the database could be initialized during the prebuild phase, and be ready for the developer.
It doesn't account for running any new migrations though. 🤔

It's entirely possible that we ought to merge this and then take another pass at the other PR.

[di]

It's entirely possible that we ought to merge this and then take another pass at the other PR.

I agree!

[abitrolly]

Good catch. Although I wouldn't depend on Elastic if it takes too much memory, depending on DB will certainly solve the problem of running initial migrations. They probably failed if the DB didn't start before web. I will try to revisit #9993, which should speed up DB init, or at least it won't be up until the DB created and SQL dump is loaded, so one less point of failure.