What’s the rationale behind conditional server startup in the phx.gen.release task?
What is RELEASE_NAME and why is it part of the condition?
1 Like
From Mix.Tasks.Release#Environment variables
The system sets different environment variables. The following variables are set early on and can only be read by
env.shandenv.bat:
…
RELEASE_NAME- the name of the release. It can be set to a custom value when invoking the release
So the second part of the conditional (System.get_env("RELEASE_NAME")) checks if mix release is generated that would set the env variable.
About the first conditional (System.get_env("PHX_SERVER"))
I guess since the release is being generated via Phoenix’s generator it assumes that at some point/condition Phoenix server will need to be started. Hence it suggests to configure it. (I’m still surprised why it’s not the default option, though). But because we can build multiple releases from the same elixir app with different purposes, it’s possible that not all releases require phoenix server to be running. Hence, conditional =)
I see it’s set in the generated rel/server.sh.eex script
However, I’m wondering if the comparison with the value is missing from the warning suggestion… because system vars are read as strings… PHX_SERVER=false would pass the conditional successfully =)
My current :prod configuration has unconditional server: true, so I’m wondering about the rationale here.
Yes, I would assume so. But the question is: why would I want to check this? Wouldn’t this always be set? Is it a proxy for checking some other condition?
Why wouldn’t I want to start the endpoint? Is this about running migrations without the endpoint serving requests?
config/runtime.exs also gets evaluated when we just run the app with mix… (like for dev, or test). Not necessary from the built release.
Why wouldn’t I want to start the endpoint? Is this about running migrations without the endpoint serving requests?
One example comes to mind - umbrella apps. As in this example: Mix.Tasks.Release#Umbrellas it builds 3 different releases. One of them, :event_processing_only doesn’t have phoenix at all, however configs, including runtime.exs, are shared between apps.
Other points, as you noted, when running mix tasks or just iex -S mix…
In Phoenix docs it also explicitly stated that server is disabled by default 
(here)
server- whentrue, starts the web server when the endpoint supervision tree starts. Defaults tofalse. Themix phx.servertask automatically sets this totrue
May be also it aligns well with “phoenix is not your app”. Like it’s an elixir project with the web-server, that can optionally be enabled… Though, I always catch myself forgetting to enable it for prod on new projects 
However, even then… there shouldn’t be harm in extra configs in the Application. It shouldn’t cause any error.
