No zip file is created

[Seeker14491]

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

[softprops]

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 hello binary 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 hello binary 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 f

[softprops]

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]

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]

About the hello binary not looking executable -- Windows has no file system attribute for a file being executable.

Running what you suggested:

PS C:\Users\seekr\Desktop\my-new-app> 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
bash-4.2# /usr/local/bin/build.sh
 Compiling semver-parser v0.7.0
 Compiling libc v0.2.44
 ...
 Finished release [optimized] target(s) in 2m 46s
bash-4.2# cd target/lambda/release/
bash-4.2# ls -al
total 6877
drwxrwxrwx 2 root root 4096 Jan 11 07:03 .
drwxrwxrwx 2 root root 0 Jan 11 07:03 ..
drwxrwxrwx 2 root root 0 Jan 11 07:00 build
-rwxr-xr-x 1 root root 0 Jan 11 07:00 .cargo-lock
drwxrwxrwx 2 root root 0 Jan 11 07:03 deps
drwxrwxrwx 2 root root 0 Jan 11 07:00 examples
drwxrwxrwx 2 root root 0 Jan 11 07:00 .fingerprint
-rwxr-xr-x 2 root root 7034726 Jan 11 07:03 hello
-rwxr-xr-x 1 root root 53 Jan 11 07:03 hello.d
drwxrwxrwx 2 root root 0 Jan 11 07:00 incremental
drwxrwxrwx 2 root root 0 Jan 11 07:00 native
bash-4.2# find -maxdepth 1 -executable -type f
./.cargo-lock
./hello
./hello.d

[Seeker14491]

It seems the problem is the find command returns other files apart from the binary, and this causes strip to fail and so the script exits early and no zip is ever made.

[Seeker14491]

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]

Thanks for the extra info. I'll try to find a more portable alternative. Let me know if you have ideas

[softprops]

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]

I'm seeing the same thing using arch linux running kernel 4.20.7.

joni@goldblum:optsched master 0 docker run --rm -v ${PWD}:/code softprops/lambda-rust
 Updating crates.io index
 Downloading crates ...
 Downloaded lambda_runtime v0.1.0
 Downloaded serde_json v1.0.38
 Downloaded serde v1.0.87
 Downloaded serde_derive v1.0.87
 Downloaded log v0.4.6
 Downloaded simple_logger v1.0.1
 Downloaded itoa v0.4.3
 Downloaded chrono v0.4.6
 Downloaded lambda_runtime_client v0.1.0
 Downloaded ryu v0.2.7
 Downloaded backtrace v0.3.13
 Downloaded hyper v0.12.23
 Downloaded http v0.1.15
 Downloaded num-integer v0.1.39
 Downloaded time v0.1.42
 Downloaded num-traits v0.2.6
 Downloaded tokio v0.1.15
 Downloaded cfg-if v0.1.6
 Downloaded syn v0.15.26
 Downloaded proc-macro2 v0.4.27
 Downloaded quote v0.6.11
 Downloaded bytes v0.4.11
 Downloaded tokio-codec v0.1.1
 Downloaded num_cpus v1.9.0
 Downloaded httparse v1.3.3
 Downloaded backtrace-sys v0.1.28
 Downloaded fnv v1.0.6
 Downloaded tokio-udp v0.1.3
 Downloaded tokio-timer v0.2.10
 Downloaded tokio-uds v0.2.5
 Downloaded tokio-tcp v0.1.3
 Downloaded rustc-demangle v0.1.13
 Downloaded tokio-sync v0.1.1
 Downloaded tokio-io v0.1.11
 Downloaded want v0.0.6
 Downloaded net2 v0.2.33
 Downloaded tokio-fs v0.1.5
 Downloaded tokio-executor v0.1.6
 Downloaded libc v0.2.48
 Downloaded tokio-current-thread v0.1.4
 Downloaded futures v0.1.25
 Downloaded iovec v0.1.2
 Downloaded futures-cpupool v0.1.8
 Downloaded autocfg v0.1.2
 Downloaded mio v0.6.16
 Downloaded tokio-threadpool v0.1.11
 Downloaded h2 v0.1.16
 Downloaded byteorder v1.3.1
 Downloaded mio-uds v0.6.7
 Downloaded slab v0.4.2
 Downloaded cc v1.0.29
 Downloaded unicode-xid v0.1.0
 Downloaded tokio-reactor v0.1.8
 Downloaded crossbeam-utils v0.6.5
 Downloaded rand v0.6.5
 Downloaded try-lock v0.2.2
 Downloaded lazycell v1.2.1
 Downloaded crossbeam v0.6.0
 Downloaded crossbeam-channel v0.3.8
 Downloaded crossbeam-deque v0.6.3
 Downloaded indexmap v1.0.2
 Downloaded lazy_static v1.2.0
 Downloaded rand_os v0.1.2
 Downloaded rand_pcg v0.1.1
 Downloaded rand_hc v0.1.0
 Downloaded rand_jitter v0.1.3
 Downloaded rand_chacha v0.1.1
 Downloaded rand_core v0.4.0
 Downloaded rand_xorshift v0.1.1
 Downloaded string v0.1.3
 Downloaded rand_isaac v0.1.1
 Downloaded parking_lot v0.7.1
 Downloaded rand_core v0.3.1
 Downloaded crossbeam-epoch v0.7.1
 Downloaded rustc_version v0.2.3
 Downloaded lock_api v0.1.5
 Downloaded parking_lot_core v0.4.0
 Downloaded memoffset v0.2.1
 Downloaded arrayvec v0.4.10
 Downloaded smallvec v0.6.8
 Downloaded owning_ref v0.4.0
 Downloaded semver v0.9.0
 Downloaded nodrop v0.1.13
 Downloaded unreachable v1.0.0
 Downloaded scopeguard v0.3.3
 Downloaded stable_deref_trait v1.1.1
 Downloaded semver-parser v0.7.0
 Downloaded void v1.0.2
 Finished release [optimized] target(s) in 12.14s
mv: ‘./bootstrap’ and ‘bootstrap’ are the same file
joni@goldblum:optsched master 1 find . -name "*.zip" -print
joni@goldblum:optsched master 0 uname -a
Linux goldblum 4.20.7-arch1-1-ARCH #1 SMP PREEMPT Wed Feb 6 18:42:40 UTC 2019 x86_64 GNU/Linux 

[j0ni]

Ah so, it looks like mine is a different issue. Looks to me like this line is never reached because the mv prior to it fails.

Note that this happens if you follow these instructions and name your binary bootstrap:

[[bin]]
name = "bootstrap"

Shall I open a new issue for this @softprops? It seems like a trivial fix.

[softprops]

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]

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.