SAM build continually updates Lambda Tools

[XXChester]

Description:
Hello AWS, is there a way to disable sam build from trying to update the lambda tools? I have the latest installed and it continually tries to upgrade them but this takes several minutes each sam build. You can see in the log below that it says it is successful in the upgrade but when I run sam build again, it again upgrades the tools (to the same version). This is causing significant development delays in my workflow so I was wondering if there is a way to disable this feature?

Installing Amazon.Lambda.Tools Global Tool
2022-03-18 09:28:12,947 | executing dotnet: ['dotnet', 'tool', 'install', '-g', 'Amazon.Lambda.Tools', '--ignore-failed-sources']
2022-03-18 09:28:13,170 |
2022-03-18 09:28:13,170 | Error installing probably due to already installed. Attempt to update to latest version.
2022-03-18 09:28:13,170 | executing dotnet: ['dotnet', 'tool', 'update', '-g', 'Amazon.Lambda.Tools', '--ignore-failed-sources']
2022-03-18 09:30:49,724 | Tool 'amazon.lambda.tools' was reinstalled with the latest stable version (version '5.3.0').
2022-03-18 09:30:49,724 | DotnetCliPackageBuilder:GlobalToolInstall succeeded

As a side note, I have uninstalled and reinstalled the tools several times with dotnet tools directly which doesn't seem to fix the issue.

SAM build continually upgrades the AWS Lambda Tools and doesn't recognize that it has installed the latest already.

Steps to reproduce the issue:

1. sam build

Observed result:
SAM doesn't detect the latest version of lambda tools is already installed in the global space
Expected result:
SAM should not try to upgrade the tools when it is already running the latest.

Additional environment details (Ex: Windows, Mac, Amazon Linux etc)
Osx, SAM CLI version 1.40.1

[XXChester]

As a temporary solution, I have hacked out the check in my local aws-sam-cli.

[mildaniel]

Thanks for reporting the issue, we will be investigating it further. Sounds like we might want to have some flag to disable the installation or add some logic to ensure we don't do this every time.

[cskeppstedt]

Seems like I have this issue now as well. Quite often my build task gets stuck (or takes a very long time) on this:

2024-01-16 10:46:55,846 | Running workflow 'DotnetCliPackageBuilder'
2024-01-16 10:46:55,846 |  Running DotnetCliPackageBuilder:GlobalToolInstall
2024-01-16 10:46:55,846 | Entered synchronized block for updating Amazon.Lambda.Tools
2024-01-16 10:46:55,847 | Installing Amazon.Lambda.Tools Global Tool
2024-01-16 10:46:55,847 | executing dotnet: ['dotnet', 'tool', 'install', '-g', 'Amazon.Lambda.Tools', '--ignore-failed-sources']

And sometimes it will retry with this message:

2024-01-16 10:45:18,446 | Error installing probably due to already installed. Attempt to update to latest version.
2024-01-16 10:45:18,447 | executing dotnet: ['dotnet', 'tool', 'update', '-g', 'Amazon.Lambda.Tools', '--ignore-failed-sources']

Same for building for .net 6 or 7, on mac osx (14.2), SAM CLI version 1.107.0

[rossobianero]

Same issue, and it's driving me crazy. In addition to the unnecessary amount of time it takes, it will often cause the build to fail (vscode on windows):

I get this error about once per day:
Failed to uninstall tool package 'amazon.lambda.tools': Access to the path 'C:\Users\Username\.dotnet\tools\.store\amazon.lambda.tools\5.9.0' is denied.

@XXChester you mentioned a "hack" workaround. Can you tell us how to do that?

BTW when the path is access denied, it's usually because dotnet-lambda.exe is hanging on to it. So, killing that process can (sometimes) get you out of that

[XXChester]

@rossobianero it was fairly simple, I located the SAM cli files and commented out the update method. I don't have it anymore as we moved away from SAM (sadly :( ) but that was is.

[cpius]

I also get stuck on GlobalToolInstall:

➜  Lambda git:(82a129b) ✗ sam build Project --debug
[...]
2024-11-11 19:02:46,744 | Found workflow 'DotnetCliPackageBuilder' to support capabilities 'Capability(language='dotnet', dependency_manager='cli-package', application_framework=None)'
2024-11-11 19:02:46,744 | Workflow DotnetCliPackageBuilder does not support value "False" for building in source. Using default value "True".
2024-11-11 19:02:46,745 | Running workflow 'DotnetCliPackageBuilder'
2024-11-11 19:02:46,745 |  Running DotnetCliPackageBuilder:GlobalToolInstall
2024-11-11 19:02:46,746 | Entered synchronized block for updating Amazon.Lambda.Tools
2024-11-11 19:02:46,746 | Installing Amazon.Lambda.Tools Global Tool
2024-11-11 19:02:46,746 | executing dotnet: ['dotnet', 'tool', 'install', '-g', 'Amazon.Lambda.Tools', '--ignore-failed-sources']
^C
Aborted!
➜  Lambda git:(82a129b) ✗ dotnet tool install -g Amazon.Lambda.Tools --ignore-failed-sources
Tool 'amazon.lambda.tools' was reinstalled with the stable version (version '5.11.2').

Where it says "Aborted!" I had to kill the command as it was stuck. Note that Amazon.Lambda.Tools already is up to date, but it doesn't matter, it gets stuck whether it is up-to-date or not. I also included the output from running the dotnet tool install command separately, which runs fine. I'm on an ARM Mac.

I work around this issue by putting a return statement in aws_lambda_builders/workflows/dotnet_clipackage/actions.py at the beginning of the execute function of the GlobalToolInstall class:

 35     def execute(self):
 36         return
 37         # run Amazon.Lambda.Tools update in sync block in case build is triggered in parallel