ci: publish Java OTel Lambda layer

[zhongkechen]

Summary

• build a Lambda layer containing only the Java OTel plugin JAR under java/lib
• exclude the Durable Java SDK and all transitive dependencies from the layer
• publish idempotent public layer versions across configured commercial AWS Regions
• support release-triggered and default-branch manual publishing for Java 17, 21, and 25

Runtime contract

• the function artifact supplies the matching Durable Java SDK and its dependencies
• the default GLOBAL provider path uses the OTel API/SDK extension surface supplied by the ADOT or OpenTelemetry Java agent layer
• configure the plugin JAR through OTEL_JAVAAGENT_EXTENSIONS and select it through DURABLE_EXECUTION_PLUGINS
• AUTO_OTLP and custom tracer-provider paths still require the function to supply their OTel SDK/exporter dependencies

Configuration

• configure the lambda-layer-publish environment with LAYER_PUBLISH_ROLE_ARN
• optionally set LAYER_PUBLISH_REGIONS; otherwise the commercial Region defaults are used
• allow release tags matching v*.*.* and the main branch for manual runs

Validation

• parsed the workflow as YAML
• checked embedded Bash syntax
• ran git diff --check
• added a ZIP-content assertion that exactly one JAR is packaged
• Maven was unavailable in the local workspace, so the layer build was not executed locally

[github-actions]

Codex AI review

[P2] Reject conditioned policies as non-public. An organization-scoped layer permission also has Principal: "*", but adds a restrictive Condition. After a statement-ID conflict, this check would accept that policy and report the layer as publicly available even though external accounts cannot use it. Require the matching statement to have no condition, and fail or replace restricted statements.

Suggested change

	)
	)
	and (.Condition == null)

[github-actions]

Codex AI review

Found one permission-validation issue. Static review only; this release/manual workflow has no PR-time execution coverage.

Reviewed commit 27c2681c7c4721aa18dc9a342a775befb086fd36. Workflow run

[github-actions]

Claude AI review

This PR adds a single CI workflow (.github/workflows/lambda-layer-publish.yml, 367 new lines) that builds an OTel-plugin-only Lambda layer and idempotently publishes public layer versions across commercial Regions. No SDK/runtime code, public API, serialization, or checkpoint/replay behavior is touched, so the Java-semantics focus areas do not apply here.

I verified the workflow against the repository facts it depends on and found them consistent:

• The copied JAR name aws-durable-execution-sdk-java-plugin-otel-${SDK_VERSION}.jar matches otel-plugin/pom.xml (artifactId=aws-durable-execution-sdk-java-plugin-otel), and LICENSE/NOTICE exist at the repo root.
• mvn -pl otel-plugin -am correctly pulls the reactor sdk/sdk-testing dependencies; SDK_VERSION derives from project.version and is tag-validated on release, matching publish_maven.yml.
• Region parsing (folded >- scalar → comma split → xargs trim), the escaped backticks in the $GITHUB_STEP_SUMMARY line, set -euo pipefail + empty-array handling, and the upload-artifact/download-artifact single-file path round-trip (dist/<LAYER_NAME>.zip) all resolve correctly.
• Idempotency (description-keyed lookup, ResourceConflictException/ResourceNotFoundException tolerance, base64 SHA-256 comparison against Content.CodeSha256) and skip-propagation via needs: build-layer are sound.

No actionable, confirmed findings.

Residual (non-blocking) risks worth noting, not raised as findings because each is a defensible design choice rather than a defect:

• Cross-run reproducibility is only checked within one runner (lambda-layer-publish.yml:171-174). A legitimate re-publish of an already-published release on a different runner image / latest plugin version could trip the Artifact hash mismatch hard failure at lambda-layer-publish.yml:277-281 instead of reusing, defeating the "idempotent" goal. This is arguably intentional drift detection.
• --compatible-runtimes java17 java21 java25 (lambda-layer-publish.yml:288) relies on java25 being an accepted Lambda runtime enum at publish time; if AWS has not yet added it, publish-layer-version would ValidationException in every Region. Could not confirm either way from the repo.
• Per the PR description, the layer build was not executed locally (Maven unavailable), and no test exercises the packaging/publish logic, so first real validation happens on a release/dispatch run.

Reviewed commit 27c2681c7c4721aa18dc9a342a775befb086fd36. Workflow run