ci: publish otel plugin lambda layer

[zhongkechen]

Summary

• add a release-triggered workflow for OTel plugin Lambda layers
• build SDK and OTel wheels once, then publish Python 3.11-3.14 layers for x86_64 and arm64
• publish under the aws-durable-execution-sdk-python-otel-plugin layer name using the lambda-layer-publish environment and LAYER_PUBLISH_ROLE_ARN
• default to all 34 commercial Lambda regions, with LAYER_PUBLISH_REGIONS as an override
• add tested layer build tooling and update release documentation

Validation

• hatch run test:all .github/scripts/tests/test_build_lambda_layer.py .github/scripts/tests/test_parse_sdk_branch.py
• hatch fmt --check .github/scripts/build_lambda_layer.py .github/scripts/tests/test_build_lambda_layer.py
• actionlint .github/workflows/lambda-layer-publish.yml .github/workflows/test-parser.yml
• built and inspected all eight runtime/architecture artifacts; each is about 24 MiB compressed and 44 MiB expanded
• verified the configured region list against Botocore Lambda endpoint metadata

[github-actions]

Codex AI review

[P2] Run the SDK-version resolver tests in CI

This explicit pytest list omits test_resolve_layer_sdk_version.py, and the root test configuration excludes .github/scripts/tests, so the newly added pin-selection logic is never tested in CI. A regression could bundle the wrong SDK version or break a release. Add the resolver test here and add .github/scripts/resolve_layer_sdk_version.py to both path filters above.

[github-actions]

Codex AI review

Found one CI wiring issue. The AWS publishing loop still lacks end-to-end coverage, leaving provider/API behavior as residual risk.

Reviewed commit 51e2a0f58e64a1af49a59b584b54fecadb5bc382. Workflow run

[github-actions]

Claude AI review

The new resolve_layer_sdk_version.py script is never exercised in CI. This pytest invocation lists test files explicitly and omits test_resolve_layer_sdk_version.py, so those tests never run — pytest only executes the two files passed as arguments. Relatedly, resolve_layer_sdk_version.py is missing from the paths filters (lines 6 and 12) that gate this workflow, unlike build_lambda_layer.py, so a change to that script alone won't even trigger this job.

This matters because resolve_layer_sdk_version.py is the guard that decides which SDK version is bundled into a published layer (pinned version for OTel-only releases; enforced-matching pin for combined releases). A regression there could publish a layer against the wrong or unpublished SDK version, and CI would stay green.

Add the test file to the pytest command (suggested below) and add .github/scripts/resolve_layer_sdk_version.py to both paths lists so source-only changes retrigger the job.

Suggested change

	python -m pytest \
	.github/scripts/tests/test_build_lambda_layer.py \
	.github/scripts/tests/test_parse_sdk_branch.py
	python -m pytest \
	.github/scripts/tests/test_build_lambda_layer.py \
	.github/scripts/tests/test_resolve_layer_sdk_version.py \
	.github/scripts/tests/test_parse_sdk_branch.py

[github-actions]

Claude AI review

This PR adds a release-triggered workflow plus two helper scripts (build_lambda_layer.py, resolve_layer_sdk_version.py) to build and publish the OTel plugin Lambda layer. It is entirely CI/release tooling — no runtime SDK, testing, OTel, or example package code changes — so checkpoint/replay, serialization, and async concurrency concerns are out of scope here.

The workflow logic is generally sound: the build-distributions job gates on otel-v releases / workflow_dispatch on main; the build-vs-download SDK steps are mutually exclusive; the region loop trims folded-YAML whitespace with xargs; and the publish step is idempotent (description carries the sha256, CodeSha256 is re-verified before reuse, and ResourceConflictException on the permission grant is tolerated). resolve_layer_sdk_version.py correctly falls back to the pinned SDK for OTel-only releases and enforces a matching pin for combined releases.

One confirmed finding (see inline): the CI job that is supposed to exercise these scripts omits the new resolve_layer_sdk_version.py from both its paths triggers and its explicit pytest file list, so test_resolve_layer_sdk_version.py never runs in CI and the version-resolution logic that determines which SDK is bundled is effectively unverified. Detail at .github/workflows/test-parser.yml:30.

Residual risk not covered by tests: build_lambda_layer._install_layer_dependencies runs a real pip install against the target platform/ABI, and list-layer-versions reuse-matching only inspects the first API page — both are exercised only by the author's manual validation, not automated tests.

Reviewed commit 51e2a0f58e64a1af49a59b584b54fecadb5bc382. Workflow run