Repository navigation
No zip file is created #2
Description
If I understand correctly from the readme, after running
docker run --rm \
-v ${PWD}:/code \
-v ${HOME}/.cargo/registry:/root/.cargo/registry \
-v ${HOME}/.cargo/git:/root/.cargo/git \
softprops/lambda-rust
my code should build and a zip file should be generated inside the target/lambda/release/ directory. The command runs without error and builds my code, yet there is no zip:
PS C:\Users\seekr\Desktop\my-new-app> ls .\target\lambda\release\
Directory: C:\Users\seekr\Desktop\my-new-app\target\lambda\release
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 1/8/2019 2:46 PM .fingerprint
d----- 1/8/2019 2:46 PM build
d----- 1/8/2019 2:49 PM deps
d----- 1/8/2019 2:46 PM examples
d----- 1/8/2019 2:46 PM incremental
d----- 1/8/2019 2:46 PM native
-a---- 1/8/2019 2:46 PM 0 .cargo-lock
-a---- 1/8/2019 2:49 PM 7034726 hello
-a---- 1/8/2019 2:49 PM 53 hello.d
I'm running these commands inside the serverless-aws-rust template project.
OS: Windows 10 x64
Activity
softprops commentedon Jan 11, 2019
Hrm. That's interesting. I don't have shell access to windows but here's a few ideas that may be factors. I put the examples together using unix conventions for volume mounts. The syntax may actually be different with windows paths. Seeing the
hellobinary there, I'm going to rule that out but it would be interesting to verify that.The other thing I see is that your shell output lists permission bits on the left. The script that runs and creates the zip queries for files in the release directory what are executable. For some reason that
hellobinary doesn't look executable.One think you might be able to try is change the default entrypoint to drop into an interactive bash
session with some following debugging tips
docker run --rm \ -it \ -v ${PWD}:/code \ -v ${HOME}/.cargo/registry:/root/.cargo/registry \ -v ${HOME}/.cargo/git:/root/.cargo/git \ --entrypoint '/bin/bash' \ softprops/lambda-rust # run the default entrypoint manually /usr/local/bin/build.sh # inspect the target/lambda/release dir cd target/lambda/release # inspect what permissions the resulting files have ls -al # inspect the list of files that we expect to zip up find -maxdepth 1 -executable -type fsoftprops commentedon Jan 11, 2019
if you can a chance can you try that and report back with any interesting insights. I'd do this myself but I don't have access to a windows machine where I can test myself
softprops commentedon Jan 11, 2019
This is new to me but I could also try experimenting with travis' new window support https://docs.travis-ci.com/user/reference/windows/#powershell
Seeker14491 commentedon Jan 11, 2019
About the hello binary not looking executable -- Windows has no file system attribute for a file being executable.
Running what you suggested:
Seeker14491 commentedon Jan 11, 2019
It seems the problem is the
findcommand returns other files apart from the binary, and this causesstripto fail and so the script exits early and no zip is ever made.Seeker14491 commentedon Jan 11, 2019
It just occurred to me why this bug is Windows specific: because Windows doesn't have an executable file system flag, everything in the mounted volume appears executable from inside the container. This breaks the assumption the script makes that the only executable file in the
target/lambda/release/directory is the binary.softprops commentedon Jan 13, 2019
Thanks for the extra info. I'll try to find a more portable alternative. Let me know if you have ideas
softprops commentedon Jan 20, 2019
I had an idea for this today that I'll try out. as an alternative to having the find command resolve executable binaries I could expose some hook that would let users specify the binary name being targetted explicitly. The serverless rust plugin already has this name handy so it would be straight format for that plugin to do that automatically in for those using the serverless framework setup. I'll do some experiments and report back with what I find
j0ni commentedon Feb 8, 2019
I'm seeing the same thing using arch linux running kernel 4.20.7.
j0ni commentedon Feb 8, 2019
Ah so, it looks like mine is a different issue. Looks to me like this line is never reached because the
mvprior to it fails.Note that this happens if you follow these instructions and name your binary
bootstrap:Shall I open a new issue for this @softprops? It seems like a trivial fix.
softprops commentedon Feb 9, 2019
To some degree this plugin renames your binary for you ( so theres less for you to configure ). What happens when you just use your default bin ( main.rs )?
softprops commentedon Feb 9, 2019
I think it would be good to handle the case of explicit renames though for robustness. I'll open an issue. I should be able to grab that this weekend.