Refuse to deploy a package missing a vendored module

A manual deploy today shipped the new lambda_function.py with a package built
from the old requirements.txt. The zip had no 'github' module, so every
invocation died at import with Runtime.ImportModuleError -- dropping all
webhook payloads, not just the log downloads -- until it was rolled back.

make prepare now starts from clean so a stale packages/ or zip cannot leak
into the artifact, and verifies the built zip actually contains every module
lambda_function.py imports before deploy can run.

Also flag in the README that make deploy is immediately live: the API Gateway
integration points at the unqualified function, so update-function-code goes
straight to $LATEST. The publish-a-version steps in that doc no longer match
how this is wired.

Author: huydhn

aws/lambda/github-status-test/Makefile

@@ -1,17 +1,34 @@
+ZIP := github-status-test-deployment.zip
+# Third-party modules lambda_function.py imports. The built zip is checked for
+# these before it can be deployed: a package missing a dependency fails at
+# import, which drops every event the webhook sends -- not just the log
+# download -- and update-function-code publishes straight to $LATEST, which is
+# what API Gateway invokes.
+VENDORED := boto3 requests github
+
 # The lambda runs on python3.9/x86_64. cryptography ships compiled wheels, so
 # pin the target platform rather than inheriting whatever python the CI runner
 # happens to default to -- otherwise the zip gets wheels the runtime can't load.
-prepare:
+# Starts from clean so a stale packages/ or zip can't leak into the artifact.
+prepare: clean
 	mkdir -p ./packages
 	pip install --target ./packages \
 		--platform manylinux2014_x86_64 --python-version 3.9 \
 		--implementation cp --only-binary=:all: --no-compile \
 		-r requirements.txt
-	cd packages && zip -r ../github-status-test-deployment.zip .
-	zip -g github-status-test-deployment.zip lambda_function.py
+	cd packages && zip -r ../$(ZIP) .
+	zip -g $(ZIP) lambda_function.py
+	$(MAKE) verify
+
+verify:
+	@for m in $(VENDORED); do \
+		unzip -l $(ZIP) | grep -qE " $$m/__init__\.py$$" \
+			|| { echo "ERROR: '$$m' missing from $(ZIP), refusing to deploy"; exit 1; }; \
+	done
+	@echo "verified: $(ZIP) contains $(VENDORED)"
 
 deploy: prepare
-	aws lambda update-function-code --function-name github-status-test --zip-file fileb://github-status-test-deployment.zip
+	aws lambda update-function-code --function-name github-status-test --zip-file fileb://$(ZIP)
 
 clean:
-	rm -rf github-status-test-deployment.zip packages
+	rm -rf $(ZIP) packages

aws/lambda/github-status-test/README.md

@@ -30,6 +30,14 @@ Notes on the app path:
 
 ### Deployment
 
+> **`make deploy` is immediately live in production.** The API Gateway integration currently points at
+> the unqualified function (`:function:github-status-test/invocations`), so `update-function-code` puts
+> the new code on `$LATEST` and every webhook hits it right away. The publish-a-version steps below are
+> stale — they describe pinning the integration to a numbered version, which is not how it is wired
+> today, and the resource id is now `xtmtzj` rather than `clc02o`. Until that is fixed, treat any deploy
+> as a direct production change: `make prepare` verifies the zip contains every vendored module before
+> `make deploy` will run, but there is no staged rollout behind it.
+
 A new version of the lambda can be deployed using `make deploy` and it will be done so automatically by the workflow
 `github-status-test-lambda` when a change is committed to main. We have limited capacity for testing this lambda at
 the moment, so additional verification steps are needed to get the new deployed version to prod. More tests and guardrails