OBS-268: Add GitHub Actions CI workflow.

[smarnach]

This workflow pushes Docker images to Google Artifact Registry for use in GCP. It will eventually replace the Circle CI workflow.

The workflow is mostly copied from Eliot, with the commands adapted to match the Circle CI workflow in this repo.

The workflow also builds a Docker image when we push to the build-test-image branch, to make it easier to build test images. We can remove this after the GCP migration (but we don't have to – it doesn't really hurt).

[willkg]

I don't understand how this branch is going to be used. In the PR description is this line:

The workflow also builds a stage image when we push to the gcp-stage branch, to make it easier to build test images. We can remove this after the GCP migration.

But I don't understand what that entails and I don't see any explanation of how we're structuring the interim period when we're deploying to both AWS and GCP environments in either the Tecken GCP project plan or OBS-268 issue.

Can you write up the plan somewhere so that we have a reference to review against?

[smarnach]

Sorry, I should have explained this better. This branch isn't really supposed to be part of the migration plan. I mainly planned to use it for two things:

• Build images for GCP before we have all the storage interface PRs merged. Currently, main is simply not suitable for that, and it will take at least another few days until it is. Since I'm already testing things in GCP, I wanted a convenient way of creating images for that. There is no automatic deployment yet – it's just so I don't have to build the test images manually.

• Build test images when working on the system tests. We have a few tickets to expand the system tests. It's likely they will fail against the new environment at some point, and then I'll need to prepare a fix. The only way to test that the fix actually works is deploying it to the GCP test environment, since the dev environment simply isn't similar enough in the aspects we are testing now, like response headers and HEAD requests.

Outside of these two cases, I don't intent to deviate from our usual model – main will be deployed to stage and version tags will be deployed to prod in both AWS and GCP.

I can also build images manually for these two cases. It's not a big issue. It just seemed more convenient and less error-prone to be able to force-push to gcp-stage to get a fresh image during the early GCP test period.

And I know I need to fill in more details in the migration plan; I'll do that later this week.

[smarnach]

I changed this a bit. First, I renamed the branch to build-test-image, because that's the intention. Second, the image is tagged test rather than latest. And third, the image is not automatically deployed anywhere.

[willkg]

I talked with Sven about the gcp-stage branch thing and he just needs a way to trigger building images while he's building out the GCP infrastructure. It's not related to deploy pipelines or the interim period where we're running Tecken in both AWS and GCP clouds.

That sounds fine to me.