alpine based image has caused CI built wrong binaries for AWS Lambda, do you still maintain another debian slim based image?
the #51 alpine based image has caused CI built wrong binaries for AWS Lambda, See https://github.com/thematters/serverless-file-post-processing/issues/441#issuecomment-938110211 because it has arch dependent npm packages (like sharp); this alpine based image has caused Lambda failure
2021-10-07T06:20:19.798Z undefined ERROR Uncaught Exception
{
"errorType": "Error",
"errorMessage": "'linuxmusl-x64' binaries cannot be used on the 'linux-x64' platform. Please remove the 'node_modules/sharp' directory and run 'npm install' on the 'linux-x64' platform.",
"stack": [
"Error: 'linuxmusl-x64' binaries cannot be used on the 'linux-x64' platform. Please remove the 'node_modules/sharp' directory and run 'npm install' on the 'linux-x64' platform.",
" at Object.hasVendoredLibvips (/var/task/node_modules/sharp/lib/libvips.js:68:13)",
after this I have manually built Lambda with sls package, got the zip file, manually upload to AWS, all worked well
/cc @anandg112 @DavideViolante after #51 merged, do you still maintain another debian slim based image? I am still researching a way to npm install different arch binary code, but the easiest way is to, maybe avoid use of serverless/github-action
@tx0c Please see this answer on Stackoverflow - https://stackoverflow.com/a/60037879
There are couple of solutions to this issue:
- You can have
.dockerignorefile and add package.lock + node_modules folders to it, then rebuild and now only use docker. - You can also install
sharpat runtime in docker
serverless/github-action@master is meant for github CI use-case to build Lambda package deployment, and AWS Lambda environment is so far all Linux-64, it's not a docker image but a zip folder of built code
https://github.com/thematters/serverless-file-post-processing/blob/develop/.github/workflows/depoy.yml#L39
You can also install sharp at runtime in docker to install sharp at every Lambda invocation? that's not feasible and a lot of extra cost
there might be still some way to work around this alpine based serverless/github-action@master, but depends on the complexity, maybe better research another clean solution without this alpine based serverless/github-action@master
Also from #25, it looks like this repo is not actively maintained? or not maintained at all? original maintainer not responding, so may have to move away sooner or late
seeing @DavideViolante still makes changes in 2022, is aware of the switching to alpine makes it unusable to glibc depended npm packages (like sharp) ?
uses: serverless/[email protected] (or master) now uses python3.10-nodejs16-slim
Let me know if this works.