[Issue #3066] Expose analytics CLI entry point in Docker

[widal001]

Summary

Exposes the analytics CLI entry point for the Docker image that allows us to run docker run <image> etl db_migrate as part of the CI/CD pipeline.

Fixes #3066

Time to review: 2 mins

Changes proposed

What was added, updated, or removed in this PR.

• Edits the poetry run pip install to use --no-cache-dir and use a wildcard for the dist/*.whl so that users don't have to change that line if we bump the version.

Context for reviewers

Testing instructions, background context, more in-depth details of the implementation, and anything else you'd like to call out or ask reviewers. Explain how the changes were verified.

To prove that the entry point is available to run from the Docker container (without poetry run) do the following steps:

1. Checkout the current PR
2. Run make release-build from the root of the /analytics/ sub-directory
3. Copy the sha256:<image-hash> from the resulting docker logs:

   => exporting to image                                                                                                      0.0s
   => => exporting layers                                                                                                     0.0s
   => => writing image sha256:14939cf59d75e1465ae5fd8030715d79ae33168bf0007346b571654a73914040                                0.0s
   

4. Use that image hash to run the following command docker run <image-hash> analytics etl --help and it should print out:

Note: Trying to run the actual DB migration with this method will fail because the migration depends on interacting with a live Postgres instance, which is what we use docker compose for but the current docker-compose.yml has the target set to dev based on this Slack thread testing it with docker compose run may not be necessary.

Additional information

Screenshots, GIF demos, code examples or output to help show the changes working as expected.

There are two main strategies for installing the package and exposing the CLI entry point:

• poetry install --only-root Not chosen because it installs an editable version of the python package (equivalent to doing pip install . -e) which is usually reserved for development
• poetry build ... && poetry run pip install ... Chosen because it first builds a stable version of the package and installs it

[coilysiren]

Almost there!

[coilysiren]

🚀 (even just what you have here was important to figure out)