fix(lambda-python-alpha): use function architecture (#18696)

[lucacucchetti]

With this change, architecture when bundling is inferred from the target architecture of the Lambda function.

Closes #18696.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

[lucacucchetti]

Hello, I tried adding an integration test but perhaps predictably bundling failed with exec format error:

 > [2/2] RUN     python -m venv /usr/app/venv &&     mkdir /tmp/pip-cache &&     chmod -R 777 /tmp/pip-cache &&     pip install --upgrade pip &&     mkdir /tmp/poetry-cache &&     chmod -R 777 /tmp/poetry-cache &&     pip install pipenv==2022.4.8 poetry==1.5.1 &&     rm -rf /tmp/pip-cache/* /tmp/poetry-cache/*:
1.204 exec /bin/sh: exec format error
------
Dockerfile:20

...

Command: docker build -t cdk-e0fb70af5dd7d3ee8ee52bbcc32ec617017cebac8121a5ccbc396830b855b75f --platform "linux/arm64" --build-arg "IMAGE=public.ecr.aws/sam/build-python3.11" "/workspace/aws-cdk/packages/@aws-cdk/aws-lambda-python-alpha/lib"
    at dockerExec (/workspace/aws-cdk/packages/aws-cdk-lib/core/lib/private/asset-staging.js:187:15)

I tested this in a GitPod environment (from the contribution guide) which I thought would closely resemble the automated PR Linter:

uname -m
x86_64

Please let me know if I should still pursue making an integ test for this situation.

ExemptionRequest Clarification Request

[kaizencc]

I am going to have this supersede #28443 because it includes the unit test asked for there. Thanks both @lucacucchetti and @mapk-amazon, I assume the important thing is to get this in.

[lucacucchetti]

Sorry about that, since I mentioned this on this issue a while back and saw no activity assumed no one was working on it.

@kaizencc do we need to get the pr-linter/exempt-integ-test label in for the Linter to pass?

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: f74728c
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[Zordrak]

I would have loved some clear documentation here. This is a major pipeline breaking change for pipelines that are developing, building and testing lambdas in x86_64 environments, but deploying the lambdas to ARM.

I am now trying to find a way to reproduce the original behaviour, but I am struggling for a viable solution.

[lucacucchetti]

I sympathise, in the original issue I commented something to that effect:

I think the contract should change, architecture should be an attribute of BundlingOptions (since it is possible in some situations to want to target one architecture while building in another), regardless, the current behaviour is not what the docs describe and so I would call it a bug.

The documented behaviour does say "platform based on the target architecture of the Lambda function".

For your case, can you do the following?

super(scope, id, {
      runtime: Runtime.PYTHON_3_11,
      bundling: {
          architecture: Architecture. X86_64,
      } as any,
      architecture: Architecture.ARM_64,
      ...

If you check the diff, bundling overrides the default of the lambda architecture.

[jbschooley]

This change broke my pipeline as well. I'm using this for layers:

bundling: {
    image: cdk.DockerImage.fromRegistry('public.ecr.aws/sam/build-python3.11:latest-arm64'),
}

to force it to use the arm64 image to build.

If I take that out and add architecture: Architecture.X86_64 it then builds with the x86 image, installing the x86 builds of dependencies (which then break my functions).

If I set architecture: Architecture.ARM64 then it passes in --platform "linux/arm64" but tries to build with the x86 image and fails.

Both architecture: Architecture.ARM64 and setting the arm64 image, it uses the image but does not pass in --platform "linux/arm64" and fails with

WARNING: The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64/v3) and no specific platform was requested
exec /usr/bin/bash: exec format error

adding platform: 'linux/arm64' to bundling does nothing.

Basically, my arm64 build seems to be broken and I have no way to update my layers without moving them, and all the functions they are used in, to x86.

[lucacucchetti]

Just to confirm, you are talking about a problem while building layers and not lambdas?

This change did not update any layer related code or behaviour.

[jbschooley]

Correct. I don't use this to build functions, I keep all my dependencies in layers. If this change didn't update layer related code then I'm not sure what happened because my layer building pipeline is broken in the same way.