Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

When git push to upgrade, server runs in dev mode. #22

Closed
loongmxbt opened this issue Nov 24, 2016 · 4 comments
Closed

When git push to upgrade, server runs in dev mode. #22

loongmxbt opened this issue Nov 24, 2016 · 4 comments

Comments

@loongmxbt
Copy link

When git push production master and then visit url, it shows

function Phoenix.LiveReloader.call/2 is undefined (module Phoenix.LiveReloader is not available)

seems it uses phoenix_live_reload module which is only for dev.

remote: $ mix release --upgrade --upfrom=0.0.1479980159 --warnings-as-errors --env=prod (/root/starsoul)
remote: ==> Assembling release..
remote: ==> Building release starsoul:0.0.1479988632 using environment prod
remote: ==> Including ERTS 8.1 from /usr/lib/erlang/erts-8.1
remote: ==> Generated .appup for starsoul 0.0.1479980159 -> 0.0.1479988632
remote: ==> Relup successfully created
remote: ==> Packaging release..
remote: ==> Release successfully built!
remote:     You can run it in one of the following ways:
remote:       Interactive: rel/starsoul/bin/starsoul console
remote:       Foreground: rel/starsoul/bin/starsoul foreground
remote:       Daemon: rel/starsoul/bin/starsoul start
remote: $ service starsoul upgrade 0.0.1479988632
remote: Release 0.0.1479988632 not found, attempting to unpack releases/0.0.1479988632/starsoul.tar.gz
remote: Unpacked successfully: "0.0.1479988632"
remote: Installed Release: 0.0.1479988632
remote: Made release permanent: "0.0.1479988632"
To root@106.14.40.86:starsoul
   3154393..723ea37  master -> master

How to solve this problem? Where did I miss? Thanks a lot!
@loongmxbt
Copy link
Author

loongmxbt commented Nov 24, 2016 •
edited

in proj_name/rel/config.exs, change default_environment to :prod and run mix gatling.deploy proj_name.

Seems when upgrade it uses the rel/config default environment setup, but first deploy will build prod.

PS:
After modifying rel/config.exs, upgrade still uses dev causes error, but deploy uses prod works fine, what did I do wrong.

Need to do service proj_name stop and service proj_name start

@loongmxbt loongmxbt reopened this Nov 24, 2016
@mrmicahcooper
Copy link
Collaborator

Hey @loongmxbt, what I typically do on the production server is globally set the MIX_ENV variable to prod

Here is a link to do this in the docs: https://github.com/hashrocket/gatling#deploying-your-app

@dennisreimann
Copy link
Contributor

I came across this too. For me the root cause of this is the sudo security policy that leads to a fresh environment for commands that run via sudo. I've added the necessary --preserve-env statements and hints with this commit: 17ca79f

@loongmxbt
Copy link
Author

We should deploy the app via a sudo user instead of the root user. Check den's guide!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@dennisreimann @mrmicahcooper @loongmxbt