Aws-sam-cli: How to point `sam local start-api` at a custom build?

[montemishkin]

This is more along the lines of a question than a feature request / bug report. Please let me know if this is an inappropriate place to ask :)

I have a C# lambda and I am trying to locally test different builds of it (with different preprocessor symbols set, etc). I am able to produce these different builds with things like dotnet lambda package -c Debug, but what I don't know how to do is point the sam local start-api command at my build.

To be clear, I am able to get sam local start-api working when I build via sam build, but it appears that I then cannot control the dotnet build "configuration", hence using dotnet lambda package instead.

The docs say:

For more compiled languages or projects that require complex packing support, we recommend that you run your own building solution, and point AWS SAM to the directory or file that contains the build artifacts.

but I don't see any way to point the command at my custom build. Anybody know how to do this? Am I missing something obvious?

[jfuss]

@montemishkin You can produce debug builds for compiled languages we support (.Net and Go) by doing the following: SAM_BUILD_MODE=debug sam build. sam build only supports two different build configurations for .Net, Release (which is the default) and Debug.

Alternatively, you could us the Makefile builder to do something more custom instead of using our default implementation.

Is this what you were looking for?

[montemishkin]

Hey @jfuss, thanks for the response :)

My question is less of a "how do I produce the more custom build" and more of a "how do I get sam local start-api to use my more custom build that I have already produced".

So in other words, supposing I've got some complicated dotnet lambda publish -foo bar --baz command to make my build, how do I get sam local start-api to use that build?

That being said, your answer does help me as a temporary workaround since I don't (yet) have more than two build configurations I want to test today, and the configurations are sufficiently straightforward for sam build to handle them.

[moelasmar]

You can do that by updating the lambda function CodeUri to refer to the directory where you build your code.
Let's say the following is your project structure:

.
├── build
│   ├── Amazon.Lambda.APIGatewayEvents.dll
│   ├── Amazon.Lambda.Core.dll
│   ├── Amazon.Lambda.Serialization.Json.dll
│   ├── HelloWorld.deps.json
│   ├── HelloWorld.dll
│   ├── HelloWorld.pdb
│   ├── HelloWorld.runtimeconfig.json
│   └── Newtonsoft.Json.dll
├── events
│   └── event.json
├── src
│   └── HelloWorld
│       ├── Function.cs
│       ├── HelloWorld.csproj
│       ├── aws-lambda-tools-defaults.json
│       ├++ bin
│       └++ obj
├── template.yaml
└── test
    └── HelloWorld.Test
        ├── FunctionTest.cs
        └── HelloWorld.Tests.csproj

You can let your lambda function configuration as following:

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function # More info about Function Resource: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction
    Properties:
      CodeUri: ./build
      Handler: HelloWorld::HelloWorld.Function::FunctionHandler
      Runtime: dotnetcore3.1

[montemishkin]

Ahh, that does the trick. Thanks for spelling it out @moelasmar! I've made a pr to add some clarification to the docs so we can hopefully save yall a little work next time a dummy like me comes along :P