Vision: Getting started with eugene

[kaaveland]

I want us to have a docker image that can be run like this:

docker run -v$(pwd)/sql:/sql --rm eugene-ci:latest

The image should be built from postgres:latest because:

1. That way, we can place a script in /docker-entrypoint-initdb.d/eugene.sh
2. postgres:latest will start a "temporary database server", then while it is running, run all shell scripts in that location
3. So we can have a throwaway database server and run traces with --commit

What should happen:

1. eugene should scan /sql and discover all sql scripts and run them in the correct order
2. the tracer can run with --commit since it's a throwaway database
3. the linter should run interspersed with the tracer and we should write a combined report

We should expose some more controls as well, probably as env vars:

1. We need some way to let the caller tell us which reports to produce
2. Output formats. We could probably let the caller place a handlebars template in the image if they want more control?
3. Probably more

This way, eugene "brings its own" postgres and a large barrier to entry goes away. What it's lacking is opportunities to "git smart" and automatically discover that we're in gitlab ci/cd or github actions, or automatically diff against main and report only on the interesting scripts. But other than that, this is almost perfectly my vision for what I want to offer and it's easy to imagine building more cool stuff, like schema linting (all FKs have index, ...).

[kaaveland]

Honestly, we don't need to rely on the postgres init setup in the image. We can write a setup that is way simpler.

Let's assume that we have a postgres installation on $PATH, then:

• We can use initdb to set up a new postgres cluster in tmp=$(mkdtemp)
• We can choose a free port then run postgres -D $tmp in a subprocess
• We can run against that db, stop it, then clean it up

That should work both on docker and elsewhere.