search

mina-deploy / mina

Blazing fast deployer and server automation tool
https://rubygems.org/gems/mina
Other
4.35k stars 490 forks source link

Make `mina console` depend on `environment`. #492

Closed Xenofex closed 7 years ago

Xenofex commented 7 years ago
  1. Fix mina console
  2. Remove .git from submodules when removing .git folder
molfar commented 7 years ago

It cant be solution... The author removed all these environment dependencies to better organize code. And tried to attach environment call to all tasks automatically. But something goes wrong, not all tasks trigger environment invoke.

Xenofex commented 7 years ago

@molfar thanks for the hint.

After some inspection, it appears that mina set the run_commands task in the default invocation chain of Rake, so that when mina console is invoked, the underlying rails console command is added in the command queue in the console task, while it is run_commands tasks triggers the command ultimately.

Though in the run_commands task, :remote is assigned as the default backend, the Commands class does NOT add environment tasks before the execution. On the other hand, I found that in Mina::DSL#run it does invoke environment before the wrapped command queue.

I guess the author meant to set the :backend runner as the default, and the :backend runner should invoke environment tasks for the user.

With above being said, my fix to mina console is definitely not correct. Though I wonder what is the supposed solution? Should we

  1. invoke environment in the :backend runner, or

  2. invoke environment in run_commands task, given that :backend runner is hard-coded here.

    Maybe @d4be4st can share your ideas?

d4be4st commented 7 years ago

You are correct @molfar

I wanted the environment task to be run only on :remote. I think the second solution is the best.

Concerning .git_modules, this is a fix for #467 ?

Could you maybe do a separate PR for that?

Xenofex commented 7 years ago

On the second thought, removing .git files in the submodules is not necessary: the git history of submodules is stored in the root .git folder, too. The .git files in the submodule paths are only a 'link' to the folders to the ones sitting in the root .git folder. With the root .git folder being deleted, the current folder is free of leaking the project history by accident.

What I was trying to fix is the error message when running bundler task, which complains that the root .git folder is missing. However the reason behind this was an entirely different story.

Basically I'm referencing my submodule as

# in Gemfile
gem 'my_subproject', path: 'vendor/my_subproject' # 'vendor/my_subproject' is a git submodule

Every time in the bundle install step of the deployment, an error message complaining that in my sub project, it cannot find the root .git folder.

I thought that it was mina which run some git task in the sub project therefore generated the error message. However I found that it was because I used the default gemspec generated by bundler, which put git ls-files in the gem files line. So that every time when the bundler needs to know what files the gem has, it invokes git ls-files. Which is, unfortunately a bad practice, because git is an external command to ruby. The best solution for me, is to use Dir#[] in the gem spec.