-
Notifications
You must be signed in to change notification settings - Fork 479
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
.NET 8 Publish with AOT on Amazon Linux still using internal docker image #1718
Comments
Needs review with the team. |
@dguisinger Good afternoon. Somehow, I'm unable to reproduce the issue.
Below is the output of
Notice the log line Could you please use the latest version of lambda tools and check if the issue is still reproducible? Thanks, |
While we figure out what is going wrong and should be able to force non-container builds by adding the |
@ashishdhingra , Regarding if I have updated to the latest and tried again, I shelved my entire project a month ago because I just didn't have time to deal with it at the moment - My entire 4-month experience with .NET 8 on Lambda been extremely frustrating... The only reason I was even pushing to do AoT was someone mentioned it fixed all of the random timeout issues he was having on .NET 7 on Lambda, similar to the issues I've been having with .NET 8 on Lambda, which you guys have also been unable to reproduce.... I suppose its also possible there is something wrong in my hand-converted project files as they started as .NET 6, moved to .NET 8, and then added AoT. I don't know if there is anything in the project file that is used when detecting what container settings to use. The CodeBuild buildspec.yml I've been using looks like this:
The configuration section of my project file looks like:
@normj thanks for that suggestion, I will try it. Just to make sure, you are saying to add --use-container-for-build false to "dotnet lambda package"? Is that flag documented? Like I mentioned in the original issue, its hard to find any real documentation around this process, it just spins up a container where I don't seem to have any control over the build setup. I wouldn't mind it building in a container if I had a clue as to how to connect to it to CodeArtifact using the IAM role that CodeBuild container is running under.... the CodeArtifact login and Nuget source registration requires executing my own pre-build commands. |
It might be documented somewhere else, but you can see slightly more details in the help command. We look at the contents of the file |
@dguisinger That switch shows up when you run
|
@Beau-Gosse-dev ... I am feeling incredibly stupid at this moment. I am so sorry for wasting everyone's time on this. I went to double check what CodeBuild had for settings after you posted that image and it was still on a different code build image. My CDK script had been updated to Amazon Linux 2 2023, but apparently it missed getting ran and I was too focused on trying to figure out how to get my Nuget source into your containerized build process, that I completely missed the CDK pipeline project hadn't been re-deployed. I redeployed the pipeline and it works |
@dguisinger No worries, it happens to all of us. Does that mean we can close the issue? |
Yes sir, I will go ahead and close it. Thanks Norm |
Comments on closed issues are hard for our team to see. |
Describe the bug
My understanding from Norm's comments in #1611 is that "dotnet lambda publish" will use a docker image if its not running on Amazon Linux.
I have tried converting my project over to AOT compiling and am using a CodeBuild image with Amazon Linux 2023 (AMAZON_LINUX_2_5). However it is still using the docker image to build.
My project needs access to CodeArtifact to download private Nuget packages.
Expected Behavior
I would expect AOT compiling to not use Docker when running inside Amazon Linux as is described.
Current Behavior
.NET 8 AOT compiling using Amazon Linux 2023 uses an AWS provided Docker image to build, causing build failures due to no customization of the build environment.
From the logs:
[Container] 2024/04/01 03:22:39.580275 Running command dotnet lambda package -pl Xxxxxxxxxxx -o output/Xxxxxxxxx.zip
217 | Amazon Lambda Tools for .NET Core applications (5.10.3)
218 | Project Home: https://github.com/aws/aws-extensions-for-dotnet-cli, https://github.com/aws/aws-lambda-dotnet
219 |
220 | Found /etc/os-release
221 | Architecture not provided, defaulting to x86_64 for container build image.
222 | Executing publish command
223 | Starting container for native AOT build using build image: public.ecr.aws/sam/build-dotnet8:latest-x86_64.
224 | ... invoking 'docker run --name tempLambdaBuildContainer-6e74898f-a244-4dad-b855-17e6f1cad8f1 --rm --volume "/codebuild/output/src1827729237/src":/tmp/source/ -i public.ecr.aws/sam/build-dotnet8:latest-x86_64 dotnet publish "/tmp/source/Xxxxxxxxxx" --output "/tmp/source/Xxxxxxxxxxx/bin/Release/net8.0/publish" --configuration "Release" --framework "net8.0" /p:GenerateRuntimeConfigurationFiles=true --runtime linux-x64 --self-contained True /p:StripSymbols=true' from directory /codebuild/output/src1827729237/src
225 | ... docker run: Unable to find image 'public.ecr.aws/sam/build-dotnet8:latest-x86_64' locally
226 | ... docker run: latest-x86_64: Pulling from sam/build-dotnet8
Reproduction Steps
I don't believe this is project code related
Possible Solution
At a minimum, documentation of this behavior seems to be lacking to completely understand how it works. Or it could be a bug that is using the Docker image to build even when its not necessary.
Additional Information/Context
I created a Q&A issue about this 5 days ago with no response, so I am escalating to a github issue.
#1712
AWS .NET SDK and/or Package version used
Amazon.Lambda.Tools 5.10.3
Targeted .NET Platform
.NET 8
Operating System and version
AmazonLinux
The text was updated successfully, but these errors were encountered: