ci: publish agnostic lambda layer

[zhongkechen]

Summary

• build one Lambda layer artifact instead of a runtime and architecture matrix
• publish the layer without compatible runtime or architecture metadata
• remove target-specific builder options and document the agnostic release behavior
• add regression coverage for the workflow configuration

Testing

• python -m pytest .github/scripts/tests/test_build_lambda_layer.py .github/scripts/tests/test_lambda_layer_publish_workflow.py .github/scripts/tests/test_parse_sdk_branch.py (5 passed)
• parsed both changed workflow YAML files successfully
• git diff --check

[github-actions]

Codex AI review

[P1] Build dependencies for every supported target. This resolves the entire layer on CPython 3.11/x86_64. opentelemetry-exporter-otlp pulls native dependencies such as grpcio, so the archive contains CPython 3.11/x86_64 extensions that fail when imported on Python 3.12-3.14 or arm64. Restore target-specific builds, or first ensure every bundled dependency is genuinely pure Python and verify the resulting archive on each supported runtime and architecture.

[github-actions]

Codex AI review

[P2] Preserve compatibility metadata on the shared version. These fields drive ListLayers/ListLayerVersions compatibility filtering; without them, consumers resolving the latest Python/architecture-compatible version will not select this release. A single version can declare all supported Python runtimes and both architectures, so publish those lists and assert their presence instead of requiring the flags to be absent.

[github-actions]

Codex AI review

Two blocking release issues: the artifact remains target-specific, and removing compatibility metadata breaks filtered layer discovery. Tests do not exercise the built archive on supported targets.

Reviewed commit 7419a76b77e99cbf00251acd3757138985f55f75. Workflow run

[github-actions]

Claude AI review

Pinning the builder to Python 3.11 on the x86_64 ubuntu-latest runner and dropping the pip cross-targeting flags (--platform/--implementation/--python-version/--abi in build_lambda_layer.py) only yields a portable layer if the dependency closure is pure-Python — it is not.

The OTel plugin declares opentelemetry-exporter-otlp, a meta-package that installs opentelemetry-exporter-otlp-proto-grpc (→ native grpcio, which has no py3-none-any wheel) and protobuf (native C++ extension, arch-specific). With pip install --only-binary :all: and no --platform/--python-version, pip resolves these to the build host's wheels: cp311 / manylinux_x86_64.

Impact: the single artifact — published with --compatible-runtimes/--compatible-architectures removed and documented as "architecture-agnostic" — actually contains x86_64/CPython-3.11 shared objects. On arm64 Lambdas the OTLP HTTP export path fails when loading the x86_64 protobuf extension, and the grpc exporter is unusable; because the compatibility metadata was also removed, Lambda no longer prevents attaching the layer to incompatible runtimes/architectures. This is a regression from the prior matrix, which built correct per-arch/per-version artifacts.

Concrete fixes (pick one): (a) restore the architecture (and, for version-specific wheels, Python) matrix and the targeting flags/metadata; (b) make the closure genuinely pure-Python — depend on opentelemetry-exporter-otlp-proto-http instead of the -otlp meta-package to drop grpcio, and force the pure-Python protobuf backend — then assert the built python/ tree contains no .so/native extensions before zipping; or (c) keep the architecture matrix (2 builds) even if you collapse the Python-version dimension, since arch is the hard portability boundary here.

[github-actions]

Claude AI review

This PR replaces the 4×2 runtime/architecture build+publish matrix with a single "agnostic" layer: it drops the pip cross-targeting flags in build_lambda_layer.py, removes --compatible-runtimes/--compatible-architectures from the publish step, and pins the builder to Python 3.11 on the x86_64 ubuntu-latest runner.

Blocking correctness issue (see inline comment on .github/workflows/lambda-layer-publish.yml:155): the layer is only agnostic if its dependency closure is pure-Python, but it isn't. The OTel plugin depends on opentelemetry-exporter-otlp, a meta-package that installs opentelemetry-exporter-otlp-proto-grpc (→ native grpcio) plus protobuf — packages that ship only platform/ABI-specific binary wheels (grpcio has no py3-none-any wheel at all). With pip install --only-binary :all: and no --platform/--python-version/--abi, these resolve to the build host's wheels (cp311 / manylinux x86_64). The published artifact therefore bakes in x86_64/CPython-3.11 shared objects while being advertised (and documented in RELEASING.md) as "Python-version- and architecture-agnostic" and published with no compatibility metadata. On arm64 Lambdas, importing the OTLP HTTP exporter path fails to load the x86_64 protobuf extension at span-export time, and any grpc path is unusable; the removed --compatible-architectures metadata also no longer prevents attaching it to incompatible functions. This is a regression versus the prior matrix, which produced correct per-arch artifacts.

Everything else in the diff (test updates, workflow trigger paths, RELEASING.md wording, the new test_lambda_layer_publish_workflow.py — parents[3] correctly resolves the repo root, and the string assertions match the updated workflow) is consistent and correct.

Residual test risk: the new tests only assert the pip command omits the removed flags and that the workflow YAML no longer contains matrix strings; nothing verifies the produced layer contains no compiled extensions (.so) or is genuinely portable. Adding a check that the installed tree contains only *-none-any wheels (or no native .so files) would catch this class of regression.

Reviewed commit 7419a76b77e99cbf00251acd3757138985f55f75. Workflow run