You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure if this is a bug or a feature request, but when running sam build --use-container for a Lambda Layer resource we have encountered a situation where it seems you can only use the makefile build method with the provided build image (apparently based on Amazon Linux 1) and there seems to be no way to use BuildMethod makefile with an image based on Amazon Linux 2 instead.
Proposal
If this is indeed not possible currently, I would like to see a way to control the image used during build (provided or provided.al2) when specifying a makefile BuildMethod.
I'm not sure if this would require changes to the SAM spec, or could perhaps be solved with a CLI flag/toggle when running sam build (or perhaps a setting in samconfig.toml)? Alternatively I could see a way of adding a new BuildMethod called makefile.al2, but I think a CLI toggle initially should do the trick.
Additional Details
Our situation is that we are using SAM to build some layers used by Python3.9 lambda runtimes, and we are using the makefile build method to install some binaries (pg_dump/pg_restore) and copy those along with their libraries to the layer for use by the lambda functions.
It seems there is a mismatch between the lambda runtime and the OS used at build time causing library version issues (Amazon Linux 1 seems to have outdated versions compared to what should be available in Amazon Linux 2).
The text was updated successfully, but these errors were encountered:
With a random requirements.txt and a Makefile in the ./layer folder:
# ./layer/Makefile
build-HelloWorldLayer:
# my system does not have yum, AL2 provided does
yum --version
mkdir -p "$(ARTIFACTS_DIR)/python"
python3 -m pip install -r requirements.txt -t "$(ARTIFACTS_DIR)/python"
Running sam build -u HelloWorldLayer seems to pull the provided AL2 build image and installed requirements successfully.
@lucashuy Thanks for the info, I compared your snippet to our templates and everything was identical except for the CompatibleRuntime setting which was set to python3.8 in our case.
I ran the SAM build command just for the layer resource as you did, and now it turns out the correct image gets used when building (whether I specify provided.al2 or python3.8, in both cases I get an AL2 based image). I took another look at our template and noticed there was also one lambda function in there with Runtime: provided.
It seems that SAM CLI prefers the provided runtime over our explicitly specified python3.8 compatible runtime for the layer when we build the entire stack via sam build. I'm not sure if that's correct behaviour, because the provided runtime appears to be the only one using a different AmazonLinux version compared to the rest of the runtimes. To me it seems to be the 'least' compatible, while SAM CLI output says:
For container layer build, first compatible runtime is chosen as build target for container.
Do you recommend I open a bug around this behaviour, or does first compatible runtime mean any existing runtime image in this context?
Describe your idea/feature/enhancement
I'm not sure if this is a bug or a feature request, but when running
sam build --use-container
for a Lambda Layer resource we have encountered a situation where it seems you can only use themakefile
build method with theprovided
build image (apparently based on Amazon Linux 1) and there seems to be no way to use BuildMethodmakefile
with an image based on Amazon Linux 2 instead.Proposal
If this is indeed not possible currently, I would like to see a way to control the image used during build (
provided
orprovided.al2
) when specifying amakefile
BuildMethod.I'm not sure if this would require changes to the SAM spec, or could perhaps be solved with a CLI flag/toggle when running
sam build
(or perhaps a setting insamconfig.toml
)? Alternatively I could see a way of adding a new BuildMethod calledmakefile.al2
, but I think a CLI toggle initially should do the trick.Additional Details
Our situation is that we are using SAM to build some layers used by Python3.9 lambda runtimes, and we are using the makefile build method to install some binaries (pg_dump/pg_restore) and copy those along with their libraries to the layer for use by the lambda functions.
It seems there is a mismatch between the lambda runtime and the OS used at build time causing library version issues (Amazon Linux 1 seems to have outdated versions compared to what should be available in Amazon Linux 2).
The text was updated successfully, but these errors were encountered: