Ruby on rails Capistrano回滚中断作业

问题似乎是，在capistrano部署期间，创建的cron作业具有预期的

RAILS\u ENV=staging

，因为部署环境是

staging

。但是，在capistrano回滚中，创建的cron作业具有

RAILS\u ENV=new\u staging

，其中

new\u staging

是要回滚的capistrano stage

我的日程文件

set :job_template, nil
job_type :rake,    "cd :path && :environment_variable=:environment bundle exec rake :task :output"

every 15.minute, roles: [:db] do
  rake "jobs:publish", output: lambda { "2>&1 >> /path/to/capistrano_directory/shared/log/jobs.log" }
end

我的部署/new_staging.rb文件

set :branch, "develop"
set :deploy_env, 'staging'
set :rails_env, 'staging'

server "user@server_ip", :web, :app, :db, :metrics
role :db, "user@server_ip", :primary => true       # This is where Rails migrations will run
ssh_options[:forward_agent] = false                                # use local SSH keys remotely

ssh_options[:paranoid] = false

set :use_sudo, false
set :deploy_to, "/path/to/capistrano_directory"
set :unicorn_conf, "#{deploy_to}/current/config/environments/#{deploy_env}/unicorn.rb"
set :unicorn_pid, "#{deploy_to}/shared/pids/unicorn.pid"

before 'deploy:finalize_update', 'set_current_release'
before "deploy:finalize_update", "deploy:update_crontab"
after 'deploy:update_code', 'deploy:symlink_db'

namespace :deploy do
  task :symlink_db, :roles => :app do
    run "ln -nfs #{deploy_to}/shared/config/database.yml #{release_path}/config/database.yml"
  end

  task :start, :roles => :app, :except => { :no_release => true } do
    run "cd #{deploy_to}/current && bundle exec unicorn -c #{unicorn_conf} -E #{deploy_env} -D"
  end

  task :stop do
    run "#{try_sudo} kill -QUIT `cat #{unicorn_pid}`"
  end

  task :restart, :roles => :app, :except => { :no_release => true } do
    run "#{try_sudo} kill -s USR2 `cat #{unicorn_pid}`"
  end
end

task :set_current_release, :roles => :app, :except => { :no_release => true } do
  set :current_release, latest_release
end

还有我的deploy.rb

require 'bundler/capistrano'
require 'capistrano/ext/multistage'
set :whenever_command, "bundle exec whenever"
set :whenever_environment, defer { stage }
set :whenever_roles, [:db, :metrics]
require "whenever/capistrano"

set :stages, %w(production staging new_staging)

set :application, "###"
set :repository,  "###"
set :deploy_via, :remote_cache
set :scm, :git

default_run_options[:shell] = '/bin/bash --login'

ssh_options[:forward_agent] = false
ssh_options[:paranoid] = false


namespace :deploy do
  desc "Update the crontab file"
  task :update_crontab do
    run "cd #{release_path} && RAILS_ENV=#{fetch(:rails_env)} bundle exec whenever --update-crontab #{application} --set environment=#{fetch(:rails_env)}"
  end
end

• 版本（0.9.7）
• Capistrano版本（2.12.0）

---

是什么导致回滚在运行时使用capistrano阶段而不是rails_env？我如何才能让它正确使用rails_env？

我对您的登台设置有点困惑（登台和新登台之间有什么区别？）。这就是说，您应该能够通过将

环境

更改为使用

rails\u env

而不是capistrano设置的

阶段

值来实现这一点：

所以

将成为：

set :whenever_environment, defer { rails_env }

---

是的，我们正在将系统的暂存环境从一个旧的拥挤的服务器转移到一个新的专用服务器上。。。我认为这可能很简单，但我不确定为什么常规部署使用了正确的变量？任务是否覆盖了它？常规部署是指部署到

生产

还是

暂存

？我认为这是可行的，因为capistrano stage与

rails\u env

相同，当您

cap new\u staging deploy

时，您将

stage

变量设置为您指定的stage（

new\u staging

），这意味着它与

rails\u env

不匹配。我可能会错过你的问题：）好吧。。。执行

bundle exec cap new_staging deploy

导致cron作业中出现

RAILS_ENV=staging

，但是

bundle exec cap new_staging deploy:rollback

导致

RAILS_ENV=new_staging

。啊，不幸的是，我不知道。它可能在回滚任务的某个地方遭到了重击。我不熟悉回滚行为，因为我通常只是重新部署一个旧版本，而不是依赖回滚。仔细看，这看起来确实像是任务手动覆盖了默认的环境配置。不知道为什么会这样做，但至少它现在起作用了

set :whenever_environment, defer { rails_env }