Dependencies in `deploy` doesn't get reexecuted on `launch`

[x-yuri]

Consider what mina-sidekiq suggests:

task :deploy do
  deploy do
    invoke :'sidekiq:quiet'
    ...
    on :launch do
      ...
      invoke :'sidekiq:restart'
    end
  end
end

sidekiq:quiet and sidekiq:restart both depend on environment task. But mina doesn't reenable prerequisites, I guess. As a result, environment task doesn't get executed on launch. And since launch and deploy commands go into separate subshells, all kinds of different things happen, like rvm not working.

I'm not sure how this is supposed to be handled, but it doesn't seem like an issue with mina-sidekiq.

Meanwhile, a workaround is to add invoke :environment at the beginning of launch.

[d4be4st]

launch is a part of deploy and a part of the same command. They are just run in different paths.

You can run mina deploy --simulate and see that it is actually one big script run one time.

That is why environment is run only once (before deploy).

I can suggest you setup your rvm to run in non-interactive shells as well. Just move the rvm initialization part in .bashrc from the bottom to the top. https://github.com/mina-deploy/mina/blob/master/docs/faq.md#--my_program-not-found-but-is-already-installed

[x-yuri]

That is why environment is run only once (before deploy).

Are you sure about that? And what do you mean by deploy? There's a deploy task, deploy method... Back in the day, environment task was called at the beginning of deploy method. But that's of no concern here.

From what I can see, mina reenables tasks being executed. That's why I can invoke the same task several times during one mina run. But it doesn't reenable prerequisites. As such, environment gets executed before sidekiq:quiet, but not before sidekiq:restart (both depend on environment task). Additionally, commands from deploy method goes to default stage, from on(:launch) to launch stage. Each stage goes into separate subshell. Therefore, environment variables I source to default stage doesn't propagate to launch stage.

I can suggest you setup your rvm to run in non-interactive shells as well.

You might be right, but it's easier for me to just source ~/.bash_profile in environment task, then moving lines on provisioning phase.

[13k]

I think the non-interactive shell is a non-issue since the deploy-specific environment should be set in :remote_environment. IMO, the deployment recipe should contain all the setup needed to successfully deploy the application and recommending "fixing" it in .bashrc is misleading.

Official plugins provide tasks/settings to properly configure the environment and recommend to invoke them in :remote_environment. Given the current behavior of :remote_environment being nested within the bootstrap stage, running in a separate subshell as @x-yuri pointed out, the environment changes made in that task don't reflect at all in other stages, which is inconsistent and should be considered a bug.

---

Here's a little test I created based on the output of mina -s deploy: https://gist.github.com/13k/01a497b7424b853fa36de26187dbed80

My test setup is:

• rbenv + ruby 2.5.0 + bundler
• bundler not installed in system ruby

The deploy script includes the generated commands from rbenv:load inside :remote_environment and I changed the generated commands from bundle:install to ruby --version && bundle version. Later in the on(:launch) stage, I replaced what would be something like bundle exec <my app server> ... with ruby --version && bundle version.

And here's the testing output:

As you can see, the correct ruby and bundler are called in the bootstrap stage, but in the launch stage, the deploy script was running the system ruby and trying to run a system bundler, because rbenv is not set up.

[ngw]

Is there any fix on this? I had to remove on :launch completely, it's quite clearly broken.