search

mweagle / Sparta

go microservices, powered by AWS Lambda
https://gosparta.io
MIT License
717 stars 48 forks source link

sparta binaries fail to execute when not built from primary directory #29

Closed kynrai closed 7 years ago

kynrai commented 7 years ago

when calling go run main.go provision with go1.7.3, the lambda functions will not work when invoked, instead the binary itself crashes with exit code 2.

repeating the process with go1.6.2 will work.

mweagle commented 7 years ago

Hi @kynrai, I'm not able to reproduce this locally using https://github.com/mweagle/SpartaHelloWorld and 1.7.3. Can you try deploying with --level debug and if the problem persists, post the logfile as a gist?

Do you see the same problem if you run locally with go run main.go --level info explore? Thanks.

kynrai commented 7 years ago

Hello, turns out the problem was when go run main.go is run outside of the directory main is in, for example go run some/dir/main.go --provision will succeed but ultimatly the lambda function will not work. feel free to close this issue. however perhaps the directory issue could be looked at as it does deploy fine but fails when invoked.

mweagle commented 7 years ago

Definitely - updated the title and will take a look. Thanks for filing.

mweagle commented 7 years ago

I think I've been able to reproduce this - if the working directory includes a main, but go run is provided a relative/absolute path to an alternative Sparta source, the resulting binary is malformed. I don't know of a way to get the absolute go run input path to set cwd during a Sparta build.

Added a FAQ entry and closing.

I would like to make this work, so if you know of a way to work around this pease LMK and reopen the issue. Thanks.