-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
With Runtime: provided
, sam build
copies source to a temp dir, breaking builds that use relative paths
#2077
Comments
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. |
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:
For now, we've returned to using shell scripts to do our packaging. |
The same problem occurs with monorepos in nodejs. It breaks common packages dependencies. So it would be nice to tell Sam build not to use temp dir |
Closing so that we can track in the above issue ( |
|
Description:
When
sam build
tries to build aruntime: provided
Function
, if the build system uses relative paths then it will fail when copied to the temporary directorysam build
uses.Steps to reproduce the issue:
Given a repository containing multiple Haskell libraries and services, structured roughly as follows:
Each service under
/service
is a separate CloudFormation stack, so I want to runsam 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 insideservice/service1
(say),sam
copies theservice1
subdirectory to a temporary location and invokesmake
.make
then invokesstack
, which fails because the dependent libraries are not present atSOME_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:
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?The text was updated successfully, but these errors were encountered: