cli: demo experience

[tgeoghegan]

We want it to be easy for prospective users of Divvi Up to give it a whirl and do some simple aggregations. To enable that, we want to make it easy to use the included compose.yaml to spin up a control plane, web app and a pair of aggregators, and then use divviup dap-client to upload and collect.

Missing pieces are:

• Distribute compose.yaml in divviup-api releases so that users don't have to check out the project (Update Docker Compose yaml to releases #1098)
• Pairing aggregators with control plane in compose setup (compose.yaml: autopair first-party leader #1099)
• rewrite cli/README.md to discuss docker compose (Rewrite demo script #1123)
• test in CI that docker compose up works (Add healthcheck for divviup-api to compose.yaml #1097)
• test demo script in CI (docker.yml: run demo script in CI #1126)
• Automatically update container images in compose.yaml
• Do something about divviup_api_vite so you can run compose.yaml without checking out sources (Only use Vite in compose.dev.yaml #1124)
• fix startup race between postgres and migrator jobs (compose.yaml rough edges #1125)
• make collector credential handling less awkward (cli: collector credential sensitive information to stdout #1033, cli: put collector credential in a dotfile #1073)
• Publish the demo script (cli/README.md) somewhere like docs.divviup.org

[inahga]

We may want to clarify the stability policy of divviup-api, now that we would effectively be shipping it to end-users.

I think we still want to be empowered to take incompatible CLI and configuration changes to divviup-api (the server) and the docker-compose file without having to care about compatibility. Maybe the policy ought to be "always download the docker-compose.yml file corresponding to the Janus release"?

[inahga]

It makes me somewhat uncomfortable how we rely on the integration-testing feature for local dev and demo to work.

Its purpose is to remove the authentication requirement and allow http URLs for aggregators, so that Janus integration tests that don't want to have to provision users or certificates can work.

Not sure if there's any action to take here, really. If anything we can break integration-testing into two features or runtime flags no-auth and allow-http, for clarity.

Long term I was hoping to replace the "no authentication required" part of integration-testing with a locally-running authentication provider (i.e. Keycloak) programmed with some fixture users, so we still can exercise authentication code paths in testing and dev. That of course won't work for the demo--I don't think we want to bother users with signing in with fake accounts.

[tgeoghegan]

In #1098, David notes:

This looks good, but the compose.yaml file still has one dependency on the surrounding repo, so it won't work standalone just yet. The divviup_api_vite service has a build stanza, and mounts the webapp source code. We'll need to either use the existing divviup_api image's bundled assets, or bake a new image with just a static web server, the webapp assets, and a way to mount an appropriate api_url file in as well. (the former may be trickier to set up since it uses host-based routing, but maybe we can make it work with setting the right environment variables to localhost with specific ports)

and also:

One other consideration: how will we phase updating the image version numbers in the compose file, tagging commits, and uploading release artifacts? For now, the compose file attached to a release will trail behind the version of the release itself. If we updated tags in the compose file before creating the release, then the compose file itself would have to go untested to some degree, since container images are generated after the release is created.