getodk / central

ODK Central is a server that is easy to use, very fast, and stuffed with features that make data collection easier. Contribute and make the world a better place! βœ¨πŸ—„βœ¨
https://docs.getodk.org/central-intro/
Apache License 2.0
127 stars 155 forks source link

Add workflow to publish nginx and service images to GHCR #676

Closed lognaturel closed 5 months ago

lognaturel commented 5 months ago

Closes #165 Progress towards https://github.com/getodk/central/issues/656

Based on #249, https://github.com/getodk/central/pull/546

TODO:

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

The built images can be seen at https://github.com/lognaturel/central/pkgs/container/central-nginx and https://github.com/lognaturel/central/pkgs/container/central-service

I have verified that the service image + nginx image with custom certs work with the standard Docker Compose file.

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

I mostly followed the groundwork laid by @mattelacchiato in #249 and then @tobiasmcnulty at #546 with some further simplifications.

I used the image naming suggested by @tobiasmcnulty: central-service and central-nginx. I considered calling them frontend and backend but I think matching the Dockerfile names is the least confusing option.

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?

It doesn't affect users yet because the images aren't used. I'm proposing splitting that off at https://github.com/getodk/central/issues/677

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

Not yet but https://github.com/getodk/central/issues/677 will.

Before submitting this PR, please make sure you have:

spwoodcock commented 5 months ago

Love this πŸ˜„

What do you think about building the images multi-arch?

Similar to pyxform-http:

            # Setup QEMU emulator to build multi-arch images
            # https://github.com/docker/setup-qemu-action
            - name: Set up QEMU
              uses: docker/setup-qemu-action@v3

            # Configure Buildx for Docker build
            # https://github.com/docker/setup-buildx-action
            - name: Set up Buildx
              uses: docker/setup-buildx-action@v3

            # Build and push Docker image with Buildx
            # https://github.com/docker/build-push-action
            - name: Build and push Docker image
              uses: docker/build-push-action@v5
              with:
                  context: .
                  push: true
                  tags: ${{ steps.meta.outputs.tags }}
                  labels: ${{ steps.meta.outputs.labels }}
                  platforms: 'linux/amd64,linux/arm64'

The main things are the two additional actions above the build + the specified platforms during the build.

lognaturel commented 5 months ago

Oh yes, I meant to add that to the todo! We can do that here. πŸ‘

spwoodcock commented 5 months ago

Although this does run on every push, so building multi-arch will add to the build time and might not make sense.

Do you think it might be good to build on release instead, or perhaps in addition?

The docker/metadata action will handle correct image tagging for releases.

lognaturel commented 5 months ago

this does run on every push

That I do have in my todo list to address! I'm just leaving it like that until all the other issues are addressed. I can add multiarch at that same time since you've told me exactly how. πŸŽ‰

lognaturel commented 5 months ago

All of this is near instant: modify .env, docker compose up -d, that's it.

lognaturel commented 5 months ago

Thanks for the review @spwoodcock and @yanokwa! Let’s merge now and then file issues as we see improvements to make.

@matthew-white I’ll definitely want your review on this when we get to https://github.com/getodk/central/issues/677 but I think for now this is a good first step.