Use pre-built images #678
Use pre-built images #678
Conversation
|
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 |
|
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. 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:
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 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 |
matthew-white
requested review from
alxndrsn
and removed request for
matthew-white
| - next | ||
| - use-images | ||
| tags: | ||
| - v*.*.* |
There was a problem hiding this comment.
Is this change to tags expected to change any behaviour?
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-servicewith versionv2024.2.0andcentral-nginxwith versionv2024.2.0AND 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 imagesThis 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:
nextbranch OR only changed documentation/infrastructure (masteris stable and used in production)