-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
Add Dotnet 8 Lambda runtime #10300
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Dotnet 8 Lambda runtime #10300
Conversation
CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅ |
I have read the CLA Document and I hereby sign the CLA |
recheck |
hmm, I can't add labels to the pr |
@dfangl @joe4dev @dominikschubert can you please help me with this PR? some checks fails due to missing git token? |
Hi @yongliu-mdsol !
If you need any help with any of these steps, please do not hesitate to ask! If this is too much of a hassle for you, please also tell us and we will take over! |
Thank you for reaching out @yongliu-mdsol 🙏 You are right 👍 . Especially with yesterday's new wave of Lambda runtime deprecations, we have 6 deprecated runtimes that need to be updated and tests need to be adjusted accordingly. These deprecations also unblock some long-awaited cleanups given that all supported Lambda runtimes are now ARM-compatible. I started tackling these updates in a separate PR #10441 |
@joe4dev yes please. if you can help me with this pr, that will be great. we are waiting for dotnet 8 in localstack to upgrade our projects. |
@yongliu-mdsol The separate PR with the deprecation updates is finally merged #10441 🙌 . It took a bit longer than expected because we took the chance to clean up our Lambda (pre-)build process and make it fully ARM-compatible. This included CI changes and further changes to our internal Pro version. I rebased your PR and edited it to align the Dotnet builds with other runtimes. We wanted to make it easier, faster, and more maintainable to add new Dotnet runtimes in the future. Therefore, I force-pushed the rebase and subsequent updates here. I hope that's ok for you. We should be able to get this one in quickly now 🚀 |
@joe4dev thank you so much for the help. |
Using the shared `dotnet` directory has a couple of limitations: | ||
* We need to use a concrete sub-directory (i.e., `dotnet6` and `dotnet8`) for pre-building | ||
* We need to clean before building to avoid picking up leftover from another Dotnet version build | ||
* Concurrent builds of Dotnet runtimes are unsafe |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- We waste one extra build cycle for the top-level
dotnet
directory.
|
||
build: | ||
mkdir -p build && \ | ||
docker run --rm -v $$(pwd)/src:/app -v $$(pwd)/build:/out $(IMAGE) bash -c "mkdir -p /app2 && cp /app/* /app2 && cd /app2 && dotnet lambda package --framework $(FRAMEWORK) --function-architecture $(FUNCTION_ARCHITECTURE) -o ../out/handler.zip" && \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is currently a flaky issue when building two Dotnet runtimes in short succession:
cd localstack/tests/aws/services/lambda_/functions/common/echo
# FAILS
make -C dotnet build && make -C dotnet6 build
# WORKS
make -C dotnet build && sleep 1 && make -C dotnet6 build
Error:
Zipping publish folder /app2/bin/Release/net6.0/publish to /out/handler.zip
... zipping: zip I/O error: No such file or directory
... zipping: zip error: Could not create output file (/out/handler.zip)
Lambda project successfully packaged: /out/handler.zip
cp: build/handler.zip: No such file or directory
make[2]: *** [build] Error 1
make[1]: *** [build] Error 2
make: *** [dotnet6] Error 2
Maybe that's related to the Docker container, which needs some time to shut down 🤔
@dfangl Do you have any suggestions on how we should guard against this to avoid a flaky build and fix it locally
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very possible that there is a race condition here. Maybe we could avoid having the same mount for both? Passing in the build folder so we have a different one for dotnet6 and dotnet8 builds?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea 👍
I fixed it using the FRAMEWORK
version as a natural build directory suffix to minimize sub-Makefile changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, nice work! Thank you @yongliu-mdsol for the PR and @joe4dev for bringing it over the line!
# Only Dotnet8 | ||
"$..environment.DOTNET_CLI_TELEMETRY_OPTOUT", | ||
"$..environment.DOTNET_NOLOGO", | ||
"$..environment.DOTNET_RUNNING_IN_CONTAINER", | ||
"$..environment.DOTNET_VERSION", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So those are only set in LocalStack, but not in AWS?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
correct 👍
(I can sneak in a clarifying comment in a later PR)
@yongliu-mdsol it will be part of the next release, which is scheduled for Thursday. |
Motivation
AWS released sam/dotnet8 image about a week ago
EDITED (@joe4dev):
AWS recently (2024-02-22) introduced the new Lambda runtime Dotnet8. We should support it in LocalStack.
Changes
Adding dotnet 8 runtime to localstack
EDITED (@joe4dev):
Testing
see shadow LocalStack PR for ext testing #10504
TODO
What's left to do: