Build docker image in CI

[richardolsson]

Description

This PR sets up a CI workflow to build a docker image and push it to the GitHub container registry.

Screenshots

None

Changes

• Adds a GitHub Actions workflow to build Docker images, that is executed when something is merged into the release branch
• Changes the Dockerfile so that NEXT.js is built into the image
• Adds .github to the .dockerignore so that github workflows do not affect the image itself

Notes to reviewer

I appreciate that this might be difficult for anyone except myself to review, but any feedback (even questions) would be useful for me to really think this through.

Related issues

Undocumented

[richardolsson]

I'd also love to hear from @benjaoming and @voxpelli. 😊

[voxpelli]

@richardolsson Looks good to me 👍

[benjaoming]

Looks great! Gonna add a further idea in a comment outside the review.

[benjaoming]

Additional speculation...

Considering that this is perhaps gradually going to mature into more automated setups, you could also additionally experiment with getting closer to some "build=>test=>deploy" pipeline... one way could be by only pushing images if the current test workflow succeeds? (I mean, you merge to release manually, so at this stage, it should be a deliberate decision).

There's also the issue that if tests sometimes break for no good reasons, then the deploy isn't started... but that's good to know if things should be more automated 💡

I think if you run the current main workflow on the release branch as well, you can write something like...

on:
  workflow_run:
    workflows: [main]
    types: [completed]
    branches: [release]

...then adding if: ${{ github.event.workflow_run.conclusion == 'success' }} in the jobs.

https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#limiting-your-workflow-to-run-based-on-branches

https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#running-a-workflow-based-on-the-conclusion-of-another-workflow

[richardolsson]

Thank you @voxpelli and @benjaoming for having a look!

Considering that this is perhaps gradually going to mature into more automated setups, you could also additionally experiment with getting closer to some "build=>test=>deploy" pipeline... one way could be by only pushing images if the current test workflow succeeds? (I mean, you merge to release manually, so at this stage, it should be a deliberate decision).

The way I've solved this for now is by setting up branch protection rules on GitHub. In order to update release, we have to make a PR, and that PR will run the tests and needs to be up to date (i.e. it is not allowed to be behind the release branch).

So the workflow will be like this:

1. Create PR from main to release (and document the changes in the PR)
2. GitHub runs all our tests on the PR, and blocks merge if it fails
3. Merge the PR into release
4. GitHub builds and pushes docker images from release
5. GitHub triggers our deployment scripts via webhook

[ziggabyte]

I don't see anything obviously strange, and I trust you, Benjamin and Pelle to have good skills around this area! Merge it!