chore(lambda): allow the architecture property to be readable from the Function #17121
Conversation
|
|
|
Title does not follow the guidelines of Conventional Commits. Please adjust title before merge. |
jcstorms1
changed the title
jcstorms1
changed the title
|
I've updated the description to clarify the motivation for this change. Thanks for taking a look! |
nija-at
changed the title
|
I have updated the Architecture property to return the correct default value. This led to several changes with multiple tests. I was able to get most of them passing but the following two are not. It looks like both are using hashing and I was hoping for some guidance on how to get them to pass as well. Thanks!
|
|
Hi @nija-at I was curious if you saw my last comment and if you had any advice on those tests? Thanks! |
| @@ -672,7 +677,7 @@ export class Function extends FunctionBase { | |||
| if (props.architectures && props.architectures.length > 1) { | |||
| throw new Error('Only one architecture must be specified.'); | |||
| } | |||
| const architecture = props.architecture ?? (props.architectures && props.architectures[0]); | |||
| const architecture = props.architecture ?? (props.architectures && props.architectures[0]) ?? Architecture.X86_64; | |||
There was a problem hiding this comment.
Oh no, this is not what I meant by my previous comment. I meant only about fixing the getter.
The change you have now will cause every CDK user's stack to change (undesirable).
However, I just decided in a different PR to leave such getters as undefined if the user has not supplied it. Let's revert this back to returning undefined if not specified.
Apologies for the churn.
Co-authored-by: Niranjan Jayakar <nija@amazon.com>
|
@nija-at apologies for the confusion. I've gone ahead and reverted the last two commits as requested and fixed the test assertion method. |
mergify
bot
dismissed
nija-at’s stale review
Pull request has been modified.
|
Hey @nija-at. I was curious if there was anything else you needed from me to get this merged? I'm hoping to have this feature available soon if possible. Thanks again! |
|
@jcstorms1 - my previous approval was discarded of the manual branch update you triggered. Don't touch the PR once approved. Our bots will do the needed changes and merge. |
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
…e Function (aws#17121) We currently have layers that are designed specifically for arm64 and x86 based functions, and a single stack may have multiple functions with varying architectures. Applying the correct layer to a large list of functions can be a tedious process that may result in applying the incorrect layer to a function. Exposing the architecture at the Function level would allow a user to easily apply the correct layer automatically during deploy by checking the value and pulling the appropriate layer for that architecture. This would eliminate or greatly reduce the possibility of applying the wrong layer type. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…e Function (aws#17121) We currently have layers that are designed specifically for arm64 and x86 based functions, and a single stack may have multiple functions with varying architectures. Applying the correct layer to a large list of functions can be a tedious process that may result in applying the incorrect layer to a function. Exposing the architecture at the Function level would allow a user to easily apply the correct layer automatically during deploy by checking the value and pulling the appropriate layer for that architecture. This would eliminate or greatly reduce the possibility of applying the wrong layer type. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
We currently have layers that are designed specifically for arm64 and x86 based functions, and a single stack may have multiple functions with varying architectures. Applying the correct layer to a large list of functions can be a tedious process that may result in applying the incorrect layer to a function. Exposing the architecture at the Function level would allow a user to easily apply the correct layer automatically during deploy by checking the value and pulling the appropriate layer for that architecture. This would eliminate or greatly reduce the possibility of applying the wrong layer type.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license