github-status-test: build the package for python3.12 (#8523)

python3.9 is past upstream EOL.

**Do not merge until the function's runtime is python3.12.** If merged
early, the deploy job fails the new runtime check and production is left
untouched — a red build rather than an outage.

Verified the dependency jump this pulls in (cryptography 43.0.3 →
50.0.0) against the real API on 3.12: token minting, the
uninstalled-repo 404, and the bad-key path all behave as before.

### Rollout

The deployed package is 3.9-built and stops loading the moment the
runtime changes, so the gap between the two steps is a live outage — API
Gateway invokes `$LATEST` unqualified, there is no staged rollout.

1. Change the function runtime to `python3.12`. **Production breaks
here.**
2. Merge this PR so main matches what is deployed.

Rollback: set the runtime back to `python3.9` and redeploy from main.

Author: huydhn

.github/workflows/github-status-test-lambda.yml

@@ -23,7 +23,7 @@ jobs:
       - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
       - uses: actions/setup-python@a26af69be951a213d495a4c3e4e4022e16d87065 # v5.6.0
         with:
-          python-version: '3.11'
+          python-version: '3.12'
           cache: pip
       - run: pip3 install -r requirements.txt pytest
       - run: pytest -v test_lambda_function.py

aws/lambda/github-status-test/Makefile

@@ -1,19 +1,25 @@
 ZIP := github-status-test-deployment.zip
+FUNCTION := github-status-test
+# Must match the deployed runtime. The package contains version-specific
+# compiled wheels (cffi), so a package built for one python on a function
+# running another fails at import on every single invocation. `deploy` checks
+# this against the live function rather than trusting the two to stay in sync.
+PYTHON_VERSION := 3.12
 # 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.
+# The lambda runs on 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.
 # 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 \
+		--platform manylinux2014_x86_64 --python-version $(PYTHON_VERSION) \
 		--implementation cp --only-binary=:all: --no-compile \
 		-r requirements.txt
 	cd packages && zip -r ../$(ZIP) .
@@ -27,8 +33,21 @@ verify:
 	done
 	@echo "verified: $(ZIP) contains $(VENDORED)"
 
-deploy: prepare
-	aws lambda update-function-code --function-name github-status-test --zip-file fileb://$(ZIP)
+# Refuse to publish a package built for a different python than the function
+# actually runs. Without this the two can drift silently and the first symptom
+# is Runtime.ImportModuleError on every webhook event.
+check-runtime:
+	@live=$$(aws lambda get-function-configuration --function-name $(FUNCTION) \
+		--query Runtime --output text); \
+	if [ "$$live" != "python$(PYTHON_VERSION)" ]; then \
+		echo "ERROR: $(FUNCTION) runs $$live but this package targets python$(PYTHON_VERSION)."; \
+		echo "       Change the function runtime first, or set PYTHON_VERSION to $${live#python}."; \
+		exit 1; \
+	fi; \
+	echo "runtime check: $(FUNCTION) runs $$live, package targets python$(PYTHON_VERSION)"
+
+deploy: check-runtime prepare
+	aws lambda update-function-code --function-name $(FUNCTION) --zip-file fileb://$(ZIP)
 
 clean:
 	rm -rf $(ZIP) packages

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

@@ -35,8 +35,12 @@ Notes on the app path:
 > 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.
+> as a direct production change: `make prepare` verifies the zip contains every vendored module and
+> `make deploy` refuses to publish a package built for a different python than the function runs, but
+> there is no staged rollout behind it.
+>
+> `PYTHON_VERSION` in the Makefile must match the function's runtime. Changing one without the other
+> breaks every invocation, so the two have to move together — see the rollout order when bumping.
 
 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