Bake lambda.zip in Docker image we ship to Dockerhub

[peterbe]

We currently generate the lambda.zip on the devs' command line, and using various scripting we upload them as assets to GitHub Releases. E.g. v1.2.0

This is clunky due to the scripting that it requires and the nuisance of having to manually ping OPs via Bugzilla that there's a new lambda.zip that needs to be deployed for AWS Lambda.

We already build the lambda.zip in CircleCI to disk. It's currently only there to make sure the command doesn't crash. Similarly, we check that generating the docs doesn't crash.

The goal is that the Lambda gets upgraded...

1. Whenever a new tag/release is made, such that Stage upgrades both the cron job and the Lambda.

2. When we ping OPs, for Prod, via Bugzilla, we shouldn't have to separate "Deploy v7.8.9 cron job" and "Deploy v7.8.9 Lambda job".

[bqbn]

We have updated our pipeline, such that whenever a new tag/release is made, Stage upgrades both the cron job and the Lambda.

We do require that whenever a new tag/releases is made, it generates the buildhub-lambda-<version>.zip file and uploads it to https://github.com/mozilla-services/buildhub/releases for us to download. As long as this contract doesn't change the automation should not break.

[peterbe]

The creation of tag/releases is already solidly in place. There's the same script that makes the release AND uploads the lambda zip to GitHub.

A more ideal form would be if we could take the .zip file, built in CircleCI and use that .zip file instead of relying on a .zip file from GitHub's releases archive.

Having said that, @mostlygeek and I have been chatting about potentially ditching Lambda entirely and switching to SQS instead. That's attractive because then we don't have to deploy two things every time (the cron and the lambda). With something like SQS we'd still have the cron job (to cover our bugs and backfilling), but the SQS would run as a daemon on the same code/server as the cron job.

[peterbe]

Actually, were are currently more interested in changing the architecture than perfecting how the Lambda is deployed. What we currently have is OKish (i.e. having to use GitHub releases) and probably good enough for now.