Github Actions support

[bmonkman]

First do an analysis to see if we are able to reproduce the functionality we have now on CircleCI.
If we are, look into the best way to do this in Github Actions. How much re-usable community code can we use?
Most likely a lot of stuff already exists for things like building, pushing images, AWS CLI support, kubectl support, etc.
After analysis, build this support into existing frontend/backend deployment pipelines and add support for choosing either CircleCI or GHA.

[dtoki]

Analysis: CirclCI <> GHAs Feature Set

The table below outlines our current feature-set utilization analysis between our existing CircleCi offering and GitHub actions (GHA) can Zero realistically offer an option to support the later (GHA) as a viable out of box solution for our CI/CD needs.

Used Circle Ci Feature	GitHub (GHA) Support
Aws-ecr (push to elastic container registry)	https://github.com/aws-actions/amazon-ecr-login first party support.
Aws-eks (interact with eks cluster)	https://github.com/marketplace/actions/eks-action existing community support.
Aws-s3 (sync with aws s3)	first party support.
Aws-cli (configure credentials)	https://github.com/aws-actions/configure-aws-credentials first party support.
queue / wait for approval (manual approval step)	sample solution https://www.aaron-powell.com/posts/2020-03-23-approval-workflows-with-github-actions/ Github community 🧵 discussing topic: https://github.bokerqi.topmunity/t/github-actions-manual-trigger-approvals/16233 some extra work needed.
version-tag	I couldn't easily find a GHA match for our current exact workflow, but we could easily recreate our current CircleCi behaviour. Alternatively, we could change how we tag images when using GHA to be more in line with some existing community solutions & standard versioning practice. We'd have to adopt semantic versioning and have a VERSION file at the root of our module repos. some extra work needed.

Some Useful Resources:

• List of some awesome curated GHAs:

• Exposed ENV Vars

• GitHub Environment Variables Action

[bmonkman]

Queue and wait for approval are separate concerns.
Wait for approval just stops the pipeline until a user manually says it should continue.
Queueing should prevent either the entire pipeline or specific tasks from running multiple times in parallel across mulitple executions of the pipeline.
The queueing orb we are using actually isn't great, so if we could find something better on GHA that would be nice. The issue with any queueing system is that most likely it requires some (probably atomic) state management system, which isn't available as a first-party option in many build pipeline tools, especially cloud-based ones.

[bmonkman]

To reproduce the version functionality we have we would just have to find some way to get a monotonically increasing number - ideally starting from 1 per pipeline.
It was nice with Circle because we were just able to use their build id that is already exposed through an env var but actually I think this is also supported in GHA with the GITHUB_RUN_NUMBER env var.

[dtoki]

To reproduce the version functionality we have we would just have to find some way to get a monotonically increasing number - ideally starting from 1 per pipeline.
It was nice with Circle because we were just able to use their build id that is already exposed through an env var but actually I think this is also supported in GHA with the GITHUB_RUN_NUMBER env var.

Right!! also just found a Community GHA that exposes some envs like GITHUB_SHA_SHORT which is exactly what we need for 1 -> 1 parity

[bmonkman]

If we use the configure aws credentials it may not be worth using that eks action, it doesn't add much aside from calling aws eks update-kubeconfig, so as long as the other action sets the config in such a way that we can use it in another step we should be fine. We may want to find or create an action that has some kubernetes tooling in it though (kubectl, kustomize, etc.)
Looks like that eks action uses the alpine k8s image alpine/k8s:1.14.6

[dtoki]

If we use the configure aws credentials it may not be worth using that eks action, it doesn't add much aside from calling aws eks update-kubeconfig, so as long as the other action sets the config in such a way that we can use it in another step we should be fine. We may want to find or create an action that has some kubernetes tooling in it though (kubectl, kustomize, etc.)
Looks like that eks action uses the alpine k8s image alpine/k8s:1.14.6

Right! I'd defiantly lean a bit more towards creating an action with kubectl, etc.. & other tools we need bundled into one if possible. I'll poke around and see how config is set and if it persists across steps.