Use pre-built images for nginx & service containers

[alxndrsn]

Related to #677

What's changed?

• docker-compose.yml now references service and nginx containers by specific version number
• github actions GHCR upload workflow has been added to the end of the Test workflow
• add a script for tagging releases and making appropriate updates to docker-compose.yml. If preferred, this could be converted to documentation

---

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

• CI
• a lot of manual testing in a forked repo (https://github.com/alxndrsn/odk-central/actions)
• ran docker compose build locally, and watched the results:

...
[+] Building 4/4
 ✔ enketo      Built      0.0s
 ✔ postgres    Built      0.0s
 ✔ postgres14  Built      0.0s
 ✔ secrets     Built      0.0s

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

The obvious alternative was to keep the GHCR workflow in its own YAML file. It should then be possible to control the triggering of that workflow via "workflow dispatch" (https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#workflow_run). However, this approach is very hard to reason about and debug, and I did not get it working. The main benefit seems to be keeping code separate, but this doesn't seem worth the effort of getting it working. If modularising the build yml become a priority, alternative approaches can be reconsidered.

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?

• should reduce the system requirements for performing upgrades
• might contain surprises for deployers who have made local changes to any of client, server, nginx etc.

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

I don't think so?

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

[lognaturel]

Nice! We can automate substituting in the tagged version in the docker compose file and then tag that commit. 👍

@matthew-white what do you think about running a script to release? The tag would then show up in Github and we could write the release notes there as usual.

I thought briefly about moving that functionality to the release Github action but that won't quite work -- we want to tag the commit that makes the change to the yml file.

I think we'll want to add some documentation on how to make code edits to frontend and backend since that will now require changes to the docker compose file as well. It's not something we highly recommend but it was easy in the past and we know some people do it.

We'll need to build from local source for the staging server. Maybe we could consider conditionally building or using an image based on a setting (could be a follow-up PR)?

[matthew-white]

I'd be OK with running a script. 👍 However, I don't understand yet the intended release process as a whole. Very possibly I'm just missing something. From the script, it looks like we'd run the script on the master branch of the central repo. But wouldn't we need to run the script on next before merging next into master? Otherwise, there would be a commit on the master branch that includes changes to the central repo without corresponding changes to central-backend and central-frontend. For example, updating Node requires changing central and sometimes also requires code changes to central-backend. If we merged that change to central into master and only then ran the script, then there'd be a commit and a short time window in which master doesn't contain working code. In other words, I'm wondering about the chance that a user could install Central at an awkward time between when the next branch is merged and the script is run. Is there a way to keep the release fully atomic? Could the script be run on the next branch instead of master? Or could the script merge next into master as part of its process?

[matthew-white]

We'll need to build from local source for the staging server.

I think this is also something that we'd need to do on the QA/test server during regression testing.