Setup Continuous Deployment with Github Actions

[alexnguyenn]

The idea is to have a Github Action workflow that can be triggered manually or listen to our compiler repo (on pushes to master or releases), which will build the docker image and deploy to AWS Lambda.

For reference:

• https://github.saobby.my.eu.orgmunity/t/triggering-by-other-repository/16163

[gwwatkin]

Agreed, this would be very nice to have. Despite the size of the Readme's section on how to deploy, deploying just an updated LSC package is not so bad because it's just a matter of updating the Lambda's code.

Here are some suggestions on how to make an action:

1. Trigger the deployment pushes to master or releases as suggested
2. Fetch the latest code, we have to options
   • Update the sub-module version in the repo, current set up, but requires writing this repo
   • Remove the submodule and instead clone a fresh new repo as part of the build process. In the future this step could be dropped if LSC becomes a package install-able from Pypi
3. Build the the python layer containing the code. Rn, this is done by 1-set-up-layer.sh. The layer holds It holds:
   • LSC + Dependencies (these will be one when LSC is uploaded to Pypi)
   • Handler code
4. Make and upload the docker image for the lambda. Done by 2-publish-image.sh.
5. Refresh the lambda's code. This step I can only do manually now, by going into the console and un-linking and re-linking the ECS repository containing the images, which should have updated with the latest image by now.

[gwwatkin]

The rest readme is interesting if we want to set up a new stack for a new stage like (dev.api.latticesurgery.com) or if we want to create a new stage for each PR to the LSC repo. It's also feasible thanks to Cloudformation, but might be somewhat more involved. Right now the process of creating new stacks is hybrid automated manual