Setting environment variables (for :start task, maybe :compile)?

[pmeinhardt]

Hi, I hope you don’t mind me bothering you 🙂 Thanks a lot for your quick replies!
I was wondering what your strategy for environment variables with bootleg is.

More specifically: I would like to pass a PORT environment variable when starting an app. For now what I did is to override the :start task in the environment – obviously a hack:

# config/deploy/production.exs

use Bootleg.Config

# …

task :start do
  remote :app do
    "PORT=20673 bin/#{Bootleg.Config.app} start"
  end
  Bootleg.UI.info "#{Bootleg.Config.app} started"
  :ok
end

Unfortunately I don't have any control over what environment the system sets by default.

I bet there's a better way, maybe you can help me out?

[brienw]

For now we pass the responsibility down to distillery. Check out https://github.com/bitwalker/distillery/blob/master/docs/Runtime%20Configuration.md

the current gist is that you would set an ENV variable on your target host and then use the REPLACE_OS_VARS/vm.args mechanism to set run-time options.

We're kind of hoping that the research/work that bitwalker is doing around deploys for Dockyard results in a nicer way to handle runtime variables. He's giving a talk at Lonestar ElixirConf in a couple weeks and i'm hoping this topic comes up

[pmeinhardt]

It sounds like it might still be desirable for Bootleg to allow passing through environment variables to the :generate_release task so Distillery has a chance to pick them up?

bootleg/lib/bootleg/tasks/build.exs

Lines 26 to 33 in a33ac9b

	task :generate_release do
	UI.info "Generating release"
	mix_env = config({:mix_env, "prod"})
	source_path = config({:ex_path, ""})
	remote :build, cd: source_path do
	"MIX_ENV=#{mix_env} mix release"
	end
	end

[brienw]

yeah, that's a good point. we could just prepend any provided ENV vars to the mix release and start commands... i like it 👍

[brienw]

brainstorming:

role :build, "build.example.com", workspace: "/tmp/build/myapp", env: %{port: 1234, var2: "foo"}

then during task the env contents could be parsed and prepended:

MIX_ENV=prod PORT=1234 VAR2=foo ... mix release

[pmeinhardt]

That looks like a nice approach to me @brienw 👍

I think you probably meant to make the :env value a Map though [nitpick 😁]

[pmeinhardt]

As an extra, it might be useful to add a BOOTLEG_ENV=<environment> to the environment variables in case people need to change release information based on the environment they deploy to. Just a thought…

[rjanja]

👍 to env role option
👍 to BOOTLEG_ENV override

[pmeinhardt]

Awesome 🙌 So looking forward to this.

Currently I am overwriting the :start, :stop, :restart and :ping tasks per environment just to set a custom VMARGS_PATH environment variable, which works – whoop – but is pretty scary at the same time 😱

Let me know if you'd like me to test-drive any changes here or I can chip in.

---

On a side note: I also hope to work on SSHKit some more in whatever time I can find and hope to get around to things like connection caching which should make deployments slightly faster. I also have some vague ideas about an alternative "backend" from the Erlang default, which could allow for ssh-agent support. As a first step though, I am currently introducing Mox for unit testing and ironing out a few smaller inconsistencies.

I'd be more than happy to hear from you guys if you have any priorities on your wishlist for SSHKit 🙏

[brienw]

I'm gonna add another Issue to track the addition of an automatic BOOTLEG_ENV variable

[brienw]

Closed by [#218]