Use pre-built images

[lognaturel]

Closes #677

There's an ordering problem that I can't quite wrap my brain around. Let's say we want to tag v2024.2.0. That means we want to produce central-service with version v2024.2.0 and central-nginx with version v2024.2.0 AND we want to use those tags in the Docker compose file. So far the only process I can think of is to put in a commit that bumps the versions in Docker compose that will fail CI, tag (which will build the images), then run CircleCI again to actually test with the new images

This would be slightly less bad if we could guarantee that the Circle CI tasks ran after the image building. I think to do that we might need to move those tasks to Github?

What has been done to verify that this works as intended?

Why is this the best possible solution? Were any other approaches considered?

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

Does this change require updates to documentation? If so, please file an issue here and include the link below.

Before submitting this PR, please make sure you have:

• branched off and targeted the next branch OR only changed documentation/infrastructure (master is stable and used in production)
• verified that any code or assets from external sources are properly credited in comments or that everything is internally sourced

[tobiasmcnulty]

This isn't a direct answer per se, but I wonder if using an environment variable to define the tag (a la the compose interpolation docs) might help work around the ordering problem? You could for example use a different TAG on CI (latest?), but still include a common .env with the current version. Users desiring more customization could even copy/create their own .env and update the version by hand when they're ready to upgrade. Anyways, perhaps there a solution in there somewhere!

[lognaturel]

Thanks for the idea, @tobiasmcnulty! I don't think it quite works with our upgrade flow and how users manage their environment variables for the standard install. We need to be able to guarantee that when a user pulls a certain tag from this repo, they get the frontend and backend code we expect. .env is under user control so I don't think we'd have any mechanism for that.

Here's another idea -- we use prefixed tags for the images and we tag those before we tag the full release. Our process would be something like:

• merge next branch to master
• tag nginx/vx.y.z to give us our tagged nginx image
• tag service/vx.y.z to give us our tagged service image
• update the docker compose file on master with the tagged images:
  • image: 'ghcr.io/getodk/central-service:service/vx.y.z'
  • image: 'ghcr.io/getodk/central-nginx:nginx/vx.y.z'
• tag the full release: vx.y.z

We could tag the versions according to the code versions tagged in the corresponding repo. If we end up with ops-only changes, we could add a -# suffix. For example, if we tag service/v2024.2.0 to publish ghcr.io/getodk/central-service:service/v2024.2.0 and then find that we have to make an ops change that affects the service image, we would tag service/v2024.2.0-1 to publish ghcr.io/getodk/central-service:service/v2024.2.0-1. Then if we make a backend patch, we would release ghcr.io/getodk/central-service:service/v2024.2.1

I think the main advantage of this approach is that everything is really explicit. The downside is that we'd end up with a lot of tags and version strings like service/v2024.2.1 that are not very aesthetic. We could think about other tagging schemes like v2024.2.1-service