revisions.log full of translation missing: en.capistrano.revision_log_message

[wdiechmann]

Steps to reproduce

Adding a second locale file to config/locales folder will have you start seeing translation missing: en.capistrano.revision_log_message in your deploy_to (using default)

At least that's what I've been able to dig my way back into – 4 months down the road when I suddenly needed the exact revision having been deployed at some time in space 😄

Expected behavior

Not sure - maybe just the 'branch $stage (at $revision) ... like it is now? I don't need any translations

Actual behavior

Branch ppe_staging (at 8ff4fcbecaff0bbfa040e7b012e92a9cab8c2f1d) deployed as release 20201209180927 by walther
Branch ppe_staging (at 8d54683921ac6412bca3c3f586eafa13b9f1ebd5) deployed as release 20201209232733 by walther
Branch ppe_staging (at 99bb5c9857ce8759a77e270516b5b38161fbf49f) deployed as release 20201210212627 by walther
Branch ppe_staging (at 6d21e39ac010c47ac527126f7cdbf4c0d7047544) deployed as release 20201210233229 by walther
translation missing: en.capistrano.revision_log_message
translation missing: en.capistrano.revision_log_message
translation missing: en.capistrano.revision_log_message
translation missing: en.capistrano.revision_log_message
translation missing: en.capistrano.revision_log_message
translation missing: en.capistrano.revision_log_message
translation missing: en.capistrano.revision_log_message
translation missing: en.capistrano.revision_log_message
translation missing: en.capistrano.revision_log_message
translation missing: en.capistrano.revision_log_message

System configuration

Environment

    Ruby     ruby 2.6.1p33 (2019-01-30 revision 66950) [x86_64-darwin18]
    Rubygems 3.0.1
    Bundler  1.17.2
    Command  /Users/walther/.asdf/installs/ruby/2.6.1/bin/cap staging doctor

Gems

    capistrano          3.11.0 (update available)
    airbrussh           1.3.1  (update available)
    rake                12.3.3 (update available)
    sshkit              1.18.0 (update available)
    net-ssh             5.1.0  (update available)
    capistrano-bundler  1.5.0  (update available)
    capistrano-rails    1.4.0  (update available)
    capistrano-rails-db 0.0.2
    capistrano-rbenv    2.1.4  (update available)
    capistrano-yarn     2.0.2
    capistrano3-puma    3.1.1  (update available)

Variables

    :application                 "ppe_staging_speicher"
    :assets_manifests            [#<Pathname:/var/www/ppe_staging_speicher/current/public/assets/.sprockets-manifest*>, #<Pathname:/var/www/ppe_staging_speicher/current/public/assets/manifest*.*>]
    :assets_prefix               "assets"
    :assets_roles                [:web]
    :branch                      "ppe_staging"
    :bundle_bins                 ["gem", "rake", "rails", "puma", "pumactl"]
    :bundle_binstubs             nil
    :bundle_clean_options        ""
    :bundle_env_variables        {}
    :bundle_flags                "--deployment --quiet"
    :bundle_gemfile              nil
    :bundle_jobs                 4
    :bundle_path                 #<Pathname:/var/www/ppe_staging_speicher/shared/bundle>
    :bundle_roles                :all
    :bundle_servers              [#<Capistrano::Configuration::Server:0x00007fdda0ce5830 @keys=[], @local=false, @user="oxenserver", @hostname="ruby2019.alco.dk", @port=nil, @properties=#<Capistrano::Configuration::Server::Properties:0x00007fdda0ce4fe8 @properties={}, @roles=#<Set: {:app, :web, :db}>>>]
    :bundle_without              "development test"
    :chruby_map_bins             ["puma", "pumactl"]
    :conditionally_migrate       false
    :default_env                 {:rbenv_root=>"$HOME/.rbenv", :rbenv_version=>"ruby-2.6.1"}
    :deploy_to                   "/var/www/ppe_staging_speicher"
    :format                      :airbrussh
    :git_shallow_clone           false
    :git_wrapper_path            "/tmp/git-ssh-ppe_staging_speicher-staging-walther.sh"
    :init_system                 :initd
    :keep_releases               5
    :linked_dirs                 ["log", "tmp/pids", "tmp/cache", "tmp/sockets", "vendor/bundle", ".bundle", "public/system", "public/uploads", "db/imports", "storage", "public/assets"]
    :linked_files                ["config/database.yml", "config/secrets.yml", ".env", ".env.staging", "config/master.key"]
    :local_user                  "walther"
    :log_level                   :debug
    :migration_role              :app
    :migration_servers           #<Capistrano::Configuration::Server:0x00007fdda0ce5830 @keys=[], @local=false, @user="oxenserver", @hostname="ruby2019.abc.co", @port=nil, @properties=#<Capistrano::Configuration::Server::Properties:0x00007fdda0ce4fe8 @properties={}, @roles=#<Set: {:app, :web, :db}>>>
    :pty                         false
    :puma_access_log             "/var/www/ppe_staging_speicher/shared/log/puma_access.log"
    :puma_bind                   "unix:///var/www/ppe_staging_speicher/shared/tmp/sockets/puma.sock"
    :puma_conf                   "/var/www/ppe_staging_speicher/shared/puma.rb"
    :puma_control_app            false
    :puma_daemonize              false
    :puma_default_control_app    "unix:///var/www/ppe_staging_speicher/shared/tmp/sockets/pumactl.sock"
    :puma_env                    :staging
    :puma_error_log              "/var/www/ppe_staging_speicher/shared/log/puma_error.log"
    :puma_init_active_record     false
    :puma_pid                    "/var/www/ppe_staging_speicher/shared/tmp/pids/puma.pid"
    :puma_preload_app            false
    :puma_rackup                 "/var/www/ppe_staging_speicher/current/config.ru"
    :puma_role                   :app
    :puma_state                  "/var/www/ppe_staging_speicher/shared/tmp/pids/puma.state"
    :puma_tag                    ""
    :puma_threads                [0, 16]
    :puma_workers                0
    :rails_env                   :staging
    :rbenv_map_bins              ["rake", "gem", "bundle", "ruby", "rails", "puma", "pumactl"]
    :rbenv_path                  "$HOME/.rbenv"
    :rbenv_prefix                "RBENV_ROOT=$HOME/.rbenv RBENV_VERSION=ruby-2.6.1 $HOME/.rbenv/bin/rbenv exec"
    :rbenv_roles                 :all
    :rbenv_ruby                  "ruby-2.6.1"
    :rbenv_ruby_dir              "$HOME/.rbenv/versions/ruby-2.6.1"
    :repo_url                    "git@gitter.abc.co:walther/ppe-speicher.git"
    :rvm_map_bins                ["puma", "pumactl"]
    :stage                       :staging
    :tmp_dir                     "/tmp"
    :yarn_bin                    :yarn
    :yarn_flags                  ["--production"]
    :yarn_prune_flags            ""
    :yarn_roles                  :all
    
    :init_system is not a recognized Capistrano setting (/Users/walther/.asdf/installs/ruby/2.6.1/lib/ruby/2.6.0/delegate.rb:83)

Servers (1)

    oxenserver@ruby2019.alco.dk [:app, :web, :db]

[leehambley]

Often times this warning means that someone has overwritten the i18n (internationalization) hash incorrectly, and has maybe blanked out a sub-section of the translations.

You can see that string, unchanged for around 5 years here

capistrano/lib/capistrano/i18n.rb

Line 26 in d369967

revision_log_message: "Branch %{branch} (at %{sha}) deployed as release %{release} by %{user}",

I'd look for any add-ons, or changes to the i18n hash in your own code, and ensure that someone isn't overwriting it too aggressively, and overwriting the built-in translation texts.

[wdiechmann]

Thx! Will do - still find it baffling when all I do (with I18n) is add da.yml- but again: thx 🙏

[leehambley]

If you share what you are doing, maybe we can shed some more light. On the end of i18n.rb (see above) you see how we ask the i18n gem to load the existing translations.

[wdiechmann]

I've trawled through all code and the only change I can find to remotely 'be in the way' of Capistrano is this one

# config/application.rb
module PpeSpeicher
  class Application < Rails::Application
    # Initialize configuration defaults for originally generated Rails version.
    config.load_defaults 6.0
    config.i18n.default_locale = :da
    config.i18n.available_locales = :da

So - I've changed that last line to config.i18n.available_locales = [:da, :en] and am crossing my fingers and holding on to my hat while I test this (later) 😆

Hopefully I can report back that it all accrues from my own [wrong]doings

[wdiechmann]

dang - I'm afraid it wasn't that easy 😢

00:57 deploy:symlink:release
      01 ln -s /var/www/ppe_staging_speicher/releases/20210323204236 /var/www/ppe_staging_speicher/releases/current
    ✔ 01 oxenserver@abc.co 0.185s
      02 mv /var/www/ppe_staging_speicher/releases/current /var/www/ppe_staging_speicher
    ✔ 02 oxenserver@abc.co 0.130s
00:57 deploy:cleanup
      translation missing: en.capistrano.keeping_releases
      01 rm -rf /var/www/ppe_staging_speicher/releases/20210312141437
    ✔ 01 oxenserver@abc.co 5.250s
01:03 deploy:log_revision
      01 echo "translation missing: en.capistrano.revision_log_message" >> /var/www/ppe_staging_speicher/revisions.log
    ✔ 01 oxenserver@abc.co 0.129s
01:03 puma:restart
      01 RBENV_ROOT=$HOME/.rbenv RBENV_VERSION=ruby-2.6.1 $HOME/.rbenv/bin/rbenv exec bundle exec pumactl -S /var/www/ppe_staging_speicher/shared/tmp/pids/puma.state -F /var/www/ppe_st…
      01 Command restart sent success
    ✔ 01 oxenserver@abc.co 0.579s

So - this is not a life threatening issue - but if you guys have any idea where I should start looking...

I know - you'd like to see what it's all about - and it's not like there is any hidden pond of gold is this small warehouse mgmt system I'm helping a friend out on but I guess I'm not too proud of the quality and missing tests and all - so I really would like just to offer bits and pieces; and if that is not enough to go on, I'm totally okay with that - then I'll just have to find that darn release version some other way

[leehambley]

Changes to config/application.rb (Rails i18n set-up, I guess) should not affect Capistrnao.

Some things to sanity check, though:

• What version is Capistrano
• What group (if any) is it in, in the Gemfile?

[wdiechmann]

hi @leehambley - it's so good of you to hang in there with me 😅

group :development do
  gem 'web-console', '>= 3.3.0'
  gem 'listen', '>= 3.0.5', '< 3.2'
  gem 'spring'
  gem 'spring-watcher-listen', '~> 2.0.0'
  gem 'capistrano', "~> 3.11", require: false
  gem 'capistrano-bundler', '~> 1.3'
  gem 'capistrano-rails', '~> 1.3'
  gem 'capistrano-rails-db'
  gem 'capistrano-rbenv', '~> 2.1'
  gem 'capistrano3-puma'
  gem 'capistrano-yarn'
end

[leehambley]

Hi @wdiechmann sorry I don't know what can be going wrong, you could try toggling those gems on-and-off and see what ones maybe do something with the I18n translations. I'm rather sure it's not a Capistrano fault.

[jclusso]

I'm having this same issue. Not sure what could cause it though?

[jclusso]

It seems that we were loading our Rails application in the deploy.rb so we could access other things and that caused this. To fix it we just added load 'capistrano/i18n' after we load the application. Is there a proper way to load your Rails application into the deploy.rb for access to things in the app. We're just using require_relative path/to/application.rb.

[mattbrictson]

Is there a proper way to load your Rails application into the deploy.rb for access to things in the app.

Short answer: no. I haven't been a maintainer of Capistrano from the beginning, so I can't speak to the intentions of its original designers, but I don't think cap was meant to support this. We monkey patch global objects in Capistrano to implement its DSL, so there is a good chance this could break your Rails code or vice versa. The i18n issue is probably just one of many weird things that might happen.

If you need to reference things from your Rails app during a cap deploy, I suggest extracting those into a separate file under lib/ so that your deploy.rb can load that file explicitly, rather than loading the entire Rails app.

[jclusso]

Unfortunately what we need to access is Rails credentials which I’m not sure we could load without just loading Rails. But thanks for the quick answer. At least I know there isn’t a “proper way” now.

[will-in-wi]

Generally when you need to use Rails credentials, you wrap whatever you are doing in a rake task and invoke that from Capistrano. It doesn't always map that easily, but something to consider.

[jclusso]

@will-in-wi thanks for the tip. I’ll have to see how I could make that work. Our Capistrano task that needs these credentials is actually installing Elasticsearch metricbeat and filebeat on the servers and making the config files for those services. Could I somehow call commands inside a Rails rake task that executes commands on those servers? I guess alternatively I could have a Rails rake task that generates the config maybe.

[will-in-wi]

The latter idea is probably how I'd do it. Have raw Capistrano install everything and then have the rake task output the config file. I'd probably use puts for the output and then redirect the output into the config file. Easier to test.

Depending on the complexity, sometimes it makes sense to use another tool for systems administration (like ansible, puppet, or chef) and then limit Capistrano to application deployment. Then you might put credentials into the systems administration deployment mechanism (like an Ansible Vault) and then dump them into environment variables which Capistrano can read.

[miao-bpl]

I have the same issue. It turns out that it comes from retrieving credentials from encrypted RAILS application.
# config/deploy.rb
require File.expand_path('./environment', __dir__)
set :user, Rails.application.credentials.dig("user".to_sym, :user)

This retrievement messes up the Capistrano's "I18n" functionality. It works after changing this configuration to
# config/deploy.rb
set :user, ENV['USER']