With `Runtime: provided`, `sam build` copies source to a temp dir, breaking builds that use relative paths

[JackKelly-Bellroy]

Description:

When sam build tries to build a runtime: provided Function, if the build system uses relative paths then it will fail when copied to the temporary directory sam build uses.

Steps to reproduce the issue:

Given a repository containing multiple Haskell libraries and services, structured roughly as follows:

/
├── lib
│   ├── lib1
│   │   └── stack.yaml
│   └── lib2
│       └── stack.yaml
└── service
    ├── service1
    │   ├── Makefile
    │   ├── samconfig.toml
    │   ├── stack.yaml
    │   └── template.yaml
    └── service2
        ├── Makefile
        ├── samconfig.toml
        ├── stack.yaml
        └── template.yaml

Each service under /service is a separate CloudFormation stack, so I want to run sam build in e.g. /service/service1. The build system for the service (currently Stack, but not relevant) refers to its dependent libraries using relative paths, saying things like "use ../../lib/library1".

Observed result:

When sam build is run inside service/service1 (say), sam copies the service1 subdirectory to a temporary location and invokes make. make then invokes stack, which fails because the dependent libraries are not present at SOME_TEMP_DIR/../../lib/library1 etc.

Expected result:

I build my code successfully.

Remarks:

As a workaround, I have been able to find my way home with this snippet, but it feels dirty:

REAL_SRC := $(shell echo "$(ARTIFACTS_DIR)" | sed 's@/.aws-sam.*@@')

I am not sure what the best fix looks like. sam's behaviour is by design, so perhaps the answer is to expose (via environment variable or similar) the repository root location and/or the original location of the source code?

[sriram-mv]

sam build copies the source code to a separate location to provide more stability and isolation to the build process. There needs to be some though on how to handle relative paths/dependencies in general.

[JackKelly-Bellroy]

Yeah, I understand the design goal. It does have some other negative implications: in the linked issue from aws-lambda-haskell-runtime there's a comment about how it breaks build caching in compiled projects.

Spitballing possible fixes:

• Doing the copy once, and then invoking make in the same tmpdir for each target would make it possible to reuse built .o files in the CodeUri directory.
• That doesn't solve the main problem - we lose a lot of caching of local libraries unless we build them in some other content-addressable way (e.g., nix)
• A config option to turn off the copy altogether would get us out of the woods, but perhaps there's a better way?

For now, we've returned to using shell scripts to do our packaging.

[mribichich]

The same problem occurs with monorepos in nodejs. It breaks common packages dependencies.
In fact I would argue to be able to turn off that feature (using a temp for) , cos for situations using webpack/bundles you don't need this behavior. And again copying only the current folder breaks local dependencies and for webpack is just a waste of time

So it would be nice to tell Sam build not to use temp dir

[torresxb1]

Closing so that we can track in the above issue (Feature request: Build in source). There's multiple open issues relating to similar problems, so we want to have a central place to track.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.