mattbrictson / airbrussh Goto Github PK

During execution of a Capistrano task, I'm seeing the following error from time to time. It looks like @position can be nil in Airbrussh::CommandFormatter.

NoMethodError: undefined method `+' for nil:NilClass
.rvm/gems/ruby-2.3.0/gems/airbrussh-1.0.1/lib/airbrussh/command_formatter.rb:75:in `number'
.rvm/gems/ruby-2.3.0/gems/airbrussh-1.0.1/lib/airbrussh/command_formatter.rb:79:in `success_message'
.rvm/gems/ruby-2.3.0/gems/airbrussh-1.0.1/lib/airbrussh/command_formatter.rb:53:in `exit_message'
.rvm/gems/ruby-2.3.0/gems/airbrussh-1.0.1/lib/airbrussh/console_formatter.rb:49:in `log_command_exit'
.rvm/gems/ruby-2.3.0/gems/airbrussh-1.0.1/lib/airbrussh/delegating_formatter.rb:25:in `public_send'
.rvm/gems/ruby-2.3.0/gems/airbrussh-1.0.1/lib/airbrussh/delegating_formatter.rb:25:in `block (3 levels) in <class:DelegatingFormatter>'
.rvm/gems/ruby-2.3.0/gems/airbrussh-1.0.1/lib/airbrussh/delegating_formatter.rb:25:in `map'
.rvm/gems/ruby-2.3.0/gems/airbrussh-1.0.1/lib/airbrussh/delegating_formatter.rb:25:in `block (2 levels) in <class:DelegatingFormatter>'
.rvm/gems/ruby-2.3.0/gems/sshkit-1.10.0/lib/sshkit/backends/netssh.rb:137:in `execute_command'
.rvm/gems/ruby-2.3.0/gems/sshkit-1.10.0/lib/sshkit/backends/abstract.rb:137:in `block in create_command_and_execute'
.rvm/gems/ruby-2.3.0/gems/sshkit-1.10.0/lib/sshkit/backends/abstract.rb:137:in `tap'
.rvm/gems/ruby-2.3.0/gems/sshkit-1.10.0/lib/sshkit/backends/abstract.rb:137:in `create_command_and_execute'
.rvm/gems/ruby-2.3.0/gems/sshkit-1.10.0/lib/sshkit/backends/abstract.rb:69:in `execute'
config/deploy.rb:93:in `block (3 levels) in <top (required)>'
.rvm/gems/ruby-2.3.0/gems/sshkit-1.10.0/lib/sshkit/backends/abstract.rb:29:in `instance_exec'
.rvm/gems/ruby-2.3.0/gems/sshkit-1.10.0/lib/sshkit/backends/abstract.rb:29:in `run'
.rvm/gems/ruby-2.3.0/gems/sshkit-1.10.0/lib/sshkit/runners/parallel.rb:12:in `block (2 levels) in execute'

Currently the remote user in the formatter is empty, if it's set in the ssh_options as opposed to in the server config:

set :application, 'foo'
set :server, 'bar.com'
set :ssh_options, auth_methods: %w(publickey), user: fetch(:application)

server fetch(:server), roles: %w(web app db)

This will display @bar.com instead [email protected] for the remote user.

how do I show the actual commands being executed as well as the airbrush indented output?

The CommandOutput Facade was introduced to support SSHKit from capistrano/sshkit@c92018d up to capistrano/sshkit@a23836c. Since none of these commits was ever released, I propose we drop support for them in Airbrussh.

This would allow us to remove the Modern CommandOutput and inline the logic from the Legacy one.

gem install -l redis-3.2.2.gem:
ERROR: Loading command: install (LoadError)
/home/test/tools/ruby/lib/ruby/2.0.0/x86_64-linux/openssl.so: undefined symbol: d2i_ECPKParameters - /home/test/tools/ruby/lib/ruby/2.0.0/x86_64-linux/openssl.so
ERROR: While executing gem ... (NoMethodError)
undefined method `invoke_with_build_args' for nil:NilClass

why? red hat 6

I'm not sure if this was intentional, but this change:

group :extras, :optional => true

Caused my call to rake to fail like this:

airbrussh:rake
There was an error in your Gemfile, and Bundler cannot continue.

I tried bundle install and I got this:

bundle install                                                                                                                                                              2.2.2
/Users/robd/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/bundler-1.9.4/lib/bundler/dependency.rb:54:in `block in initialize': undefined method `to_sym' for {:optional=>true}:Hash (NoMethodError)

Basically, looks like :optional => true is not backwards compatible with older versions of bundler. I'm not sure if this was intentional - looks like the intention was for v1.10 of bundler to only be needed for people who wanted to run the optional tasks, but this doesn't work

I upgraded bundler, reinstalled the gems and then I saw:

airbrussh:rake                                                                                                                                                                        2.2.2
rake aborted!
LoadError: cannot load such file -- chandler/tasks
/Users/robd/dev/airbrussh/Rakefile:14:in `require'

This can be fixed by patching the rake file like this, (but I don't know what gem version find_all_by_name was added):

if !ENV["TRAVIS"] &&  Gem::Specification::find_all_by_name('chandler').any?
  require "chandler/tasks"
  task "release:rubygem_push" => "chandler:push"

I'm not sure what the motivation was as far as making some gems optional. I think it is a nice idea in principle, but I wonder if the complexity of trying to make them optional is worth it. Personally I'm happy to just install everything even if I don't use guard, chandler etc.

I'm happy to do a PR for this, but I wanted to discuss first to find out which direction it should go in.

Running Airbrussh from Pseudoterminals (PTY) never outputs anything. Take this script for example:

require "pty"

PTY.spawn("cap staging deploy") do |stdout, stdin, pid|
  begin
    stdout.each { |line| print line }
  rescue Errno::EIO
  end
end

Console Width gets calculated to 0 (make sense - there's no actual console / window this is running from). Can be easily fixed by setting config.truncate = false.

Not sure if this is something you want to add to the README or have it skip truncation if console_width ends up being 0.

Does airbrussh work on Windows? I hope so, but haven't been able to verify this.

It would be nice to add Windows-based CI to the gem to make this verification automatic, as I've done for the chandler gem using AppVeyor:

https://github.com/mattbrictson/chandler/blob/7deaef595024edac0166b164c5d58afa6429a497/appveyor.yml

Hi, thanks for the great work, airbrussh really makes capistrano looks better! :)

I've a question. I've a simple task like this:

namespace :logs do
  desc 'Tailf production logs'
  task :tail do
    on roles(:app) do
      set :format, :pretty
      execute :tail, '-f', release_path.join('log', "#{fetch(:rails_env, 'production')}.log")
    end
  end
end

But now with airbrussh all the logs goes to the log/capistrano.log. Is there a way to change this?

Currently, if you call the same command multiple times, airbrussh doesn't really print out the right thing.
Below is some sample output, which I've annotated with the problems as I see them:

on_local("repeated_command_test") do
  execute(:echo, "command 1")
  execute(:echo, "command 1")
  execute(:echo, "command 2")
  execute(:echo, "command 1")
end

# output_lines :
  "      01 echo command 1\n",
  "      01 command 1\n",
  "    ✔ 01 test_user@localhost 0.004s\n",
# Missing start line and position number not incremented for Command 1 the second time
  "      01 command 1\n", # Wrong position number for stdout, should be 2
  "    ✔ 01 test_user@localhost 0.004s\n", # Wrong position number for end line
  "      02 echo command 2\n",
  "      02 command 2\n",
  "    ✔ 02 test_user@localhost 0.003s\n",
# Missing start line and position number goes back to 1 for Command 1 the third time
  "      01 command 1\n", # Wrong position number for stdout, should be 4
  "    ✔ 01 test_user@localhost 0.004s\n" # Wrong position number for end line

I propose to increment the command position in these cases, so it's clear which instance of the command the output belongs to. In order to achieve this, I'm thinking we could rely on the command uuid and enhance the command history to store all command executions, even if they have the same command string.

My idea is to modify the command history so it is never cleared. It would therefore be a complete command history rather than just being the history for the most recent task. I would store each command, in order as they are started. I would also store the current rake task against each command at the time the command is started.

I would then reimplement the methods which rely on the command history (eg first_execution, position, etc) using the new full command history.

As well as supporting repeated commands, I think this would make the code easier to reason about. At the moment I find the behaviour to do with clearing the history, storing the last task name and adding new commands hard to understand.

@mattbrictson Does this make sense? Should I look into this?

This is the best changelog entry I've ever seen. It tells me exactly what I need to know, in such a friendly way.

Please close this issue once you realize how awesome you are.

I'm using just Capfile and rake task files.

# Capfile
require 'capistrano/setup'
require 'airbrussh/capistrano'

Dir[File.expand_path('./lib/tasks/**/*.rake', __dir__)].each { |f| import f }

set :stage, :production
set :log_level, :debug

# example of rake task
namespace :ubuntu do
  task :update do
    on roles(:ubuntu) do
      execute 'sudo apt-get -qq update && sudo apt-get -qq -y upgrade'
    end
  end

It turns out that airbrussh is not loaded - I had to put following code at the end of Capfile

SSHKit.config.output = Airbrussh::Formatter.new($stdout)

It is same on sshkit 1.7.1 and 1.6.1. I'm using capistrano 3.4.0

For some historic reasons, I can't easily use passwordless sudo, so I'm using this gem: https://github.com/kentaroi/sshkit-sudo, which handles capturing the password.

The problem is that the following log lines don't make it through to the console:

DEBUG [7e0bb996]    [sudo] password for whoever: 
DEBUG [7e0bb996]    
DEBUG [7e0bb996]    Sorry, try again.
DEBUG [7e0bb996]    
DEBUG [7e0bb996]    [sudo] password for whoever: 

Is there a way I can tell airbrussh to allow these lines to be shown?

Using airbrussh 1.1.0 (w/ capistrano 3.6.0 and ruby 2.1.7), I intermittently get a LoadError printing certain non-ASCII text. Sometimes it prints OK, sometimes it blows up.

This is the backtrace for a string containing the Unicode character "𝄞" (U+1D11E):

LoadError: dlopen(enc/trans/single_byte.so, 9): image not found - enc/trans/single_byte.so
gems/airbrussh-1.1.0/lib/airbrussh/console.rb:83:in `encode'
gems/airbrussh-1.1.0/lib/airbrussh/console.rb:83:in `utf8_supported?'
gems/airbrussh-1.1.0/lib/airbrussh/console.rb:42:in `truncate_to_console_width'
gems/airbrussh-1.1.0/lib/airbrussh/console.rb:26:in `print_line'
gems/airbrussh-1.1.0/lib/airbrussh/console_formatter.rb:112:in `print_line'
gems/airbrussh-1.1.0/lib/airbrussh/console_formatter.rb:117:in `print_indented_line'
gems/airbrussh-1.1.0/lib/airbrussh/console_formatter.rb:42:in `block in log_command_data'
gems/airbrussh-1.1.0/lib/airbrussh/console_formatter.rb:41:in `each_line'
gems/airbrussh-1.1.0/lib/airbrussh/console_formatter.rb:41:in `log_command_data'
gems/airbrussh-1.1.0/lib/airbrussh/delegating_formatter.rb:25:in `public_send'
gems/airbrussh-1.1.0/lib/airbrussh/delegating_formatter.rb:25:in `block (3 levels) in <class:DelegatingFormatter>'
gems/airbrussh-1.1.0/lib/airbrussh/delegating_formatter.rb:25:in `map'
gems/airbrussh-1.1.0/lib/airbrussh/delegating_formatter.rb:25:in `block (2 levels) in <class:DelegatingFormatter>'

I fixed it by also rescueing LoadError here: https://github.com/mattbrictson/airbrussh/blob/master/lib/airbrussh/console.rb#L84

Any ideas on what could be going wrong here, or would you be open to a PR to add a rescue @mattbrictson?

I see the error below [1] from the console truncation code on master. In certain circumstances, the string coming back from net ssh seems to be ASCII-8BIT encoded (this happens when I am logging a string containing a left quotation mark ‘), and this causes appending the ellipsis to fail, I guess because it cannot be converted into ASCII-8BIT.

I added some logging like this to the truncate_to_console_width method:

string.chop! while strip_ascii_color(string).length >= width
more_string = "…\e[0m"
p [string.encoding, more_string.encoding]
string << more_string

Most of the strings coming back from the server give this debug:
[#<Encoding:UTF-8>, #<Encoding:UTF-8>]

It is just the one containing the quotation mark which gives this debug:
[#<Encoding:ASCII-8BIT>, #<Encoding:UTF-8>]

I'm not sure why net ssh is returning ASCII-8BIT in this case or what the right thing to do is. Changing from an ellipsis to 3 periods (...) fixes the problem, I guess because they can be converted to ASCII-8BIT. I'm not sure what is going on here, but I thought I'd make a note of it since it appears to be caused by Airbrussh truncation.

[1]

SSHKit::Runner::ExecuteError: Exception while executing as xxxx: incompatible character encodings: ASCII-8BIT and UTF-8
sshkit-c840d4f63f41/lib/sshkit/runners/parallel.rb:16:in `rescue in block (2 levels) in execute'
sshkit-c840d4f63f41/lib/sshkit/runners/parallel.rb:12:in `block (2 levels) in execute'
Encoding::CompatibilityError: incompatible character encodings: ASCII-8BIT and UTF-8
airbrussh-6191c3937d5d/lib/airbrussh/console.rb:48:in `truncate_to_console_width'
airbrussh-6191c3937d5d/lib/airbrussh/console.rb:26:in `print_line'
airbrussh-6191c3937d5d/lib/airbrussh/console_formatter.rb:112:in `print_line'
airbrussh-6191c3937d5d/lib/airbrussh/console_formatter.rb:117:in `print_indented_line'
airbrussh-6191c3937d5d/lib/airbrussh/console_formatter.rb:42:in `block in log_command_data'
airbrussh-6191c3937d5d/lib/airbrussh/console_formatter.rb:41:in `each_line'
airbrussh-6191c3937d5d/lib/airbrussh/console_formatter.rb:41:in `log_command_data'
airbrussh-6191c3937d5d/lib/airbrussh/delegating_formatter.rb:25:in `public_send'
airbrussh-6191c3937d5d/lib/airbrussh/delegating_formatter.rb:25:in `block (3 levels) in <class:DelegatingFormatter>'
airbrussh-6191c3937d5d/lib/airbrussh/delegating_formatter.rb:25:in `map'
airbrussh-6191c3937d5d/lib/airbrussh/delegating_formatter.rb:25:in `block (2 levels) in <class:DelegatingFormatter>'
sshkit-c840d4f63f41/lib/sshkit/backends/netssh.rb:93:in `block (4 levels) in execute_command'
net-ssh-2.9.2/lib/net/ssh/connection/channel.rb:569:in `call'

If there is an error while deploying, airbrussh will not log the Backtrace output.
This will not be logged:

00:07 deploy:check:repo_dir
      01 mkdir -p /opt/test/
    ✔ 01 @test
(Backtrace restricted to imported tasks)
cap aborted!
NameError: undefined local variable or method `aaa' for #<SSHKit::Backend::Local:0x007fd45d3bbf30>
/opt/capistrano/tasks/bundle_rsync.cap:54:in `block (5 levels) in <top (required)>'
/opt/capistrano/tasks/bundle_rsync.cap:53:in `block (4 levels) in <top (required)>'
/opt/capistrano/tasks/bundle_rsync.cap:52:in `block (3 levels) in <top (required)>'
Tasks: TOP => bundle_rsync:rsync_release => bundle_rsync:npm:install
(See full trace by running task with --trace)
The deploy has failed with an error: undefined local variable or method `aaa' for #<SSHKit::Backend::Local:0x007fd45d3bbf30>

** DEPLOY FAILED
** Refer to test.log for details. Here are the last 20 lines:

It would be great if all the output would be logged, and not only the capistrano output

(Airbrussh is really sweet BTW!)

As a result of #48, which removes first_execution? from Rake::Command I wonder if Rake::Command is no longer holding it's weight. I think perhaps we should move the @position attribute from the Rake::Command on to the CommandFormatter and delete the Rake::Command class. I think this is a simple change which could be achieved like this:

# Context
# Replace decorate_command with a position method:
def position
  history.index(command.to_s)
end

# ConsoleFormatter
# Pass the position to the CommandFormatter as a constructor arg in decorate:
def decorate(command)
  Airbrussh::CommandFormatter.new(command, @context.position(command))
end

# CommandFormatter
# Change the one use of position to use the new attribute:
def number
  format("%02d", @position + 1)
end

The upside of this change is that we no longer have to double wrap the Command, and it makes it easier to see where the @position is coming from on the CommandFormatter. Since the position is only used on the CommandFormatter I think it makes sense for it to be an attribute on there.

@mattbrictson Do you think this would be an improvement? Am I missing anything here?

Currently only on default :pretty format I can see within's value:

DEBUG [b165746b] Running if test ! -d /var/www; then echo "Directory does not exist '/var/www'" 1>&2; false; fi on localhost
DEBUG [b165746b] Command: if test ! -d /var/www; then echo "Directory does not exist '/var/www'" 1>&2; false; fi
INFO [f9a188e9] Running /usr/bin/env vendor/bin/phinx migrate on localhost
DEBUG [f9a188e9] Command: cd /var/www && /usr/bin/env vendor/bin/phinx migrate

Under air I can't and should guess this:

00:00 deploy:db_migrate
      01 vendor/bin/phinx migrate

It would be nice to see something like:

00:00 deploy:db_migrate
      01 within: /var/www
      01 vendor/bin/phinx migrate

I dont' know which label, icon better to use.
May be also remove deploy_to from all pathes, but what I need to see is concrete path, where current command executed.

Test coverage is a good place now, and most refactoring is also done. What's next for airbrussh?

We've received multiple reports (from @Startouf and @dan-klasson in capistrano/capistrano#1669) that important error messages are not being rendered by Airbrussh.

Specifically, the color of the message is indistinguishable from the background color of the terminal, making them "invisible".

Suggestions of how to reproduce this (what OS and terminal is affected?) and how to fix it would be greatly appreciated.

Non rails apps don't necessarily have a directory called log; it might be good to check for it's existence and create it to avoid error

As suggested by @justindowning:

For my uses, could we add a flag that could be called per task to not output the write_banner? This would encourage more machine readable output for tasks the depend on it. Thanks!

airbrussh/lib/airbrussh/formatter.rb

Lines 55 to 59 in e3a8c5a

	def write_banner
	return if @log_file.nil?
	print_line "Using airbrussh format."
	print_line "Verbose output is being written to #{blue(@log_file)}."
	end

It looks like when minitest starts, it scans for minitest plugin gems and tries to load guard-minitest, which is not compatible with Ruby 1.9.

https://travis-ci.org/mattbrictson/airbrussh/jobs/68626916#L164

/home/travis/.rvm/gems/ruby-1.9.3-p551/gems/listen-3.0.0/lib/listen.rb:2:in `require': /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/listen-3.0.0/lib/listen/logger.rb:26: unknown type of %string (SyntaxError)
    %i(fatal error warn info debug).each do |meth|

With the old pretty formatter, the Message Level (fatal, error, warn, info...) was colorized. That made it quite easy for the human eye to see where the error messages are.

I wrote an informal patch that overrides the write_log_message method in CommandFormatter to restore the old colorize behaviour. It combines code from SSHKIT ( https://github.com/capistrano/sshkit/blob/v1.11.2/lib/sshkit/formatters/pretty.rb#L44 ) with the Airbrussh::Colors method.

Would you like a Pull Request for this change?

require 'airbrussh'

module Airbrussh
  class ConsoleFormatter < SSHKit::Formatter::Abstract
    include Airbrussh::Colors

    LEVEL_NAMES = %w{ DEBUG INFO WARN ERROR FATAL }.freeze
    LEVEL_COLORS = [:gray, :blue, :yellow, :red, :red].freeze # pretty formatter had :black, airbrussh colors has gray

    private

    def write_log_message(log_message)
      return if debug?(log_message)
      print_task_if_changed
      verbosity = log_message.verbosity
      # level = colorize(LEVEL_NAMES[verbosity].rjust(6), LEVEL_COLORS[verbosity])
      level = LEVEL_NAMES[verbosity].ljust(6)
      log_string = send(LEVEL_COLORS[verbosity], level + log_message.to_s)
      print_indented_line(log_string)
    end
  end
end

This change is also available in my fork in the branch colorize-logmessage https://github.com/klyonrad/airbrussh/tree/colorize-logmessage

We have some duplication between Airbrussh and SSHKit in terms of the colorization code. Is there a nice way to consolidate this code for the simplification of both projects?

This is a continuation of the discussion started here: capistrano/capistrano#1509 (comment)

@robd I took a look at this last night, and immediately I ran into some difficulty. Airbrussh and SSHKit approach colorization from opposite directions: Airbrussh applies colors regardless, and then strips the ANSI color escape codes conditionally during output (in Console); SSHKit applies colors conditionally, based on the output of the formatter.

I'm not sure if either approach is necessarily better, but they are at odds. Do you have any ideas of how to approach it?

Here's an idea suggested by @robd:

One thing I have considered is adding support to SSHKit for multiple formatters. I was thinking this might allow us to remove all the SSHKit Pretty formatting related tests from Airbrussh, and remove the management of the Pretty formatted file Logger. One gotcha is the 'last 20 lines of output' currently relies on Airbrussh having access to the pretty formatter.

Perhaps how this could work is that we introduce a new formatter to handle the logging duplication. In other words, logging events come into this formatter and are duplicated and emitted to multiple destination formatters.

This "dispatcher" would eliminate the need for dealing with the Pretty logger inside Airbrussh::Formatter itself, which would simplify the code and tests quite a bit.

As @robd mentions, the one coupling that still remains is the "last 20 lines of output" problem. Perhaps a separate decorator could handle the responsibility of buffering Pretty's IO? Sounds like some more discussion needed on this point.

Related:

Another thing which I don't like is when I removed color codes from the log file it unfortunately made the 'last 20 lines of output' message uncolored. Ideally we would show last 20 lines of output with colors on the terminal, but not write character codes to the log file.

In any case, I think it makes sense to introduce the multi-formatter handling in airbrussh first, and then we can contribute it to SSHKit if it proves to be flexible and useful.

Configuration

Windows 7 64 bits

$ ruby --version
ruby 1.9.3p551 (2014-11-13) [i386-mingw32]

$ bundler list
Gems included by the bundle:
  * airbrussh (0.5.0)
  * breakpoint (2.5.0)
  * bundler (1.10.3)
  * capistrano (3.4.0)
  * chunky_png (1.3.4)
  * colorize (0.7.7)
  * compass (1.0.3)
  * compass-core (1.0.3)
  * compass-import-once (1.0.5)
  * ffi (1.9.8)
  * highline (1.7.2)
  * i18n (0.7.0)
  * multi_json (1.11.1)
  * net-scp (1.2.1)
  * net-ssh (2.9.2)
  * normalize-scss (3.0.2)
  * rainbow (2.0.0)
  * rake (10.4.2)
  * rb-fsevent (0.9.5)
  * rb-inotify (0.9.5)
  * sass (3.4.15)
  * sassy-maps (0.4.0)
  * scss-lint (0.38.0)
  * sshkit (1.7.1)
  * susy (2.2.5)

Issue

I get the following error when executing the command cap staging deploy --trace:

cap aborted!
NameError: uninitialized constant Airbrussh::SimpleDelegator
C:/Ruby193/lib/ruby/gems/1.9.1/gems/airbrussh-0.5.0/lib/airbrussh/command_formatter.rb:7:in `<module:Airbrussh>'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/airbrussh-0.5.0/lib/airbrussh/command_formatter.rb:5:in `<top (required)>'
C:/Ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
C:/Ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/airbrussh-0.5.0/lib/airbrussh/formatter.rb:2:in `<top (required)>'
C:/Ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
C:/Ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/airbrussh-0.5.0/lib/airbrussh.rb:2:in `<top (required)>'
C:/Ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
C:/Ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/airbrussh-0.5.0/lib/airbrussh/capistrano.rb:1:in `<top (required)>'
C:/Ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:60:in `require'
C:/Ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:60:in `rescue in require'
C:/Ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:35:in `require'
C:/Users/micbou/www/scaffolder/Capfile:16:in `<top (required)>'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/rake-10.4.2/lib/rake/rake_module.rb:28:in `load'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/rake-10.4.2/lib/rake/rake_module.rb:28:in `load_rakefile'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/rake-10.4.2/lib/rake/application.rb:689:in `raw_load_rakefile'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/rake-10.4.2/lib/rake/application.rb:94:in `block in load_rakefile'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/rake-10.4.2/lib/rake/application.rb:176:in `standard_exception_handling'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/rake-10.4.2/lib/rake/application.rb:93:in `load_rakefile'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/rake-10.4.2/lib/rake/application.rb:77:in `block in run'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/rake-10.4.2/lib/rake/application.rb:176:in `standard_exception_handling'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/rake-10.4.2/lib/rake/application.rb:75:in `run'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/capistrano-3.4.0/lib/capistrano/application.rb:15:in `run'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/capistrano-3.4.0/bin/cap:3:in `<top (required)>'
C:/Ruby193/bin/cap:23:in `load'
C:/Ruby193/bin/cap:23:in `<main>'

It was working fine with the 0.4.1 version.

This is the last bit of testing needed to bring our coverage to 100%.

Good idea from @robd, who wrote:

change the formatter tests to execute a real rake task and get rid of the Airbrussh::Rake::Context.current_task_name = xxx declarations in the tests. I had a crack at this in robd/airbrussh@ebdad32

This could follow a pattern similar to what is used Rake::ContextTest to define and invoke rake tasks during tests. The define_and_invoke_rake_task helper could be shared via a mixin, defined in test/support.

Airbrussh currently runs fine on Ruby 1.9 and up. However since Ruby's maintainers have officially dropped all support for 1.9, it doesn't really make sense to devote our time to supporting a dead version of Ruby.

Can Airbrussh safely stop supporting 1.9? Are there a lot of Airbrussh users still on 1.9? (Seems there is at least one.)

Suggestions, speculation, and discussion welcome! 😃

Here are some ideas:

• Maintain 1.9 support as long as SSHKit and Capistrano do
• Drop 1.9 support now (no time like the present!)
• Wait until Airbrussh 1.0 (which will be…?)

/cc @robd @carlesso

If something goes wrong during a Capistrano deployment, Airbrussh prints a message like this:

** DEPLOY FAILED
** Refer to log/capistrano.log for details. Here are the last 20 lines:

[[snip]]

However, Airbrussh honors the :truncate setting when printing these last 20 lines. In other words, by default these lines will be cut off with an … character based on the console width. This severely limits the troubleshooting utility of this output.

I consider this a bug. Airbrussh should never truncate the output when displaying the tail of the log file.

Starting with airbrussh 0.5.0, the command numbers in the output are no longer sequential. They still count upwards, but there are gaps in the sequence.

00:11 deploy:symlink:linked_dirs
      01 mkdir -p /home/deployer/apps/myapp/releases/20150707153735/public /home/deployer/apps/myapp/releases…
    ✔ 01 deployer@remote-ip 0.325s
      04 ln -s /home/deployer/apps/myapp/shared/public/assets /home/deployer/apps/myapp/releases/201507071537…
    ✔ 04 deployer@remote-ip 0.077s
      07 rm -rf /home/deployer/apps/myapp/releases/20150707153735/log
    ✔ 07 deployer@remote-ip 0.074s
      08 ln -s /home/deployer/apps/myapp/shared/log /home/deployer/apps/myapp/releases/20150707153735/log
    ✔ 08 deployer@remote-ip 0.087s
      11 ln -s /home/deployer/apps/myapp/shared/tmp/pids /home/deployer/apps/myapp/releases/20150707153735/tm…
    ✔ 11 deployer@remote-ip 0.392s
      14 ln -s /home/deployer/apps/myapp/shared/tmp/cache /home/deployer/apps/myapp/releases/20150707153735/t…
    ✔ 14 deployer@remote-ip 0.361s
      17 ln -s /home/deployer/apps/myapp/shared/tmp/sockets /home/deployer/apps/myapp/releases/20150707153735…
    ✔ 17 deployer@remote-ip 0.367s
      20 ln -s /home/deployer/apps/myapp/shared/public/system /home/deployer/apps/myapp/releases/201507071537…
    ✔ 20 deployer@remote-ip 0.080s

Am I correct in assuming that this only works with Capistrano 3?

The Context class is built around the assumption that a given Rake task is fully completed before moving onto the next task. For example, even when Capistrano is deploying to multiple servers in parallel, the concurrency happens within a single task. In other words, all SSH executions for that task must finish before moving onto the next task.

However this assumption fails when Capistrano's invoke DSL is used within an SSHKit on block. Doing this leads to scenarios where one Rake task partially executes, then another task, and then back to the original task. In a multi-server deployment, this task switching can happen at different times in different threads.

Airbrussh::Rake::Context fails to track the current task in such scenarios. In fact, Airbrussh's entire output formatting is predicated on the linear progression of Rake tasks.

I don't know if a redesign is warranted, but it is certainly something to think about, especially if invoke is used this way often.

Perhaps the solution is to use a stack to track task execution, rather than a single variable, and to keep a separate stack in each thread.

See original discussion in #78.

I have this rake task:

namespace :logs do
  desc "tail rails log" 
  task :tail_rails do
    on roles(:app) do
      execute "tail -f #{shared_path}/log/#{fetch(:rails_env)}.log"
    end
  end
end

This task tails production rails log if set :format, :pretty in deploy.rb
But without any format specified and gem airbrussh formatting capistrano output, the task doesn't show anything. capistrano.log is getting the log correctly.
It would be nicer to have the log through airbrussh.
Is there any config to do that?

Great job!
Alfredo.

Hello :)

First of all, I have to say that this library is a real gem! ;) Adding it to my projects at the moment.

While doing so, I noticed the require statement:

require "airbrussh/capistrano"

But AFAIK all other Capistrano plugins follow the reverse pattern:

require "capistrano/rbenv"
require "capistrano/bundler"
require "capistrano/rails"
...

It seems that this gem will be better if it's rearranged to allow the same require pattern:

require "capistrano/airbrussh"

<3

I have a Capistrano task for rails runner remote execution:

require 'shellwords'

namespace :invoke do

  desc "Execute rails runner on a remote server"
  task :runner do
    if ENV['COMMAND']
      on roles(:app) do
        within current_path do
          with rails_env: fetch(:rails_env) do
            execute :rails, :runner, ENV['COMMAND'].shellescape
          end
        end
      end

    else
      puts "\n\nFailed! You need to specify the 'COMMAND' parameter",
           "Usage: cap <stage> invoke:runner COMMAND=your-command"
    end
  end

end

In this task, but only in this one, I would like to disable truncation. Is it possible to access to Airbrussh formatter within the task in order to set truncation to false?

The truncate auto does not seem to take into account that you are adding on extra ellipsis characters to the length of the string. I think this is only a UTF-8 Safe string issue but here is the code I created to create the issue. Also this issue comes up in the capistrano gem when deploying however that is a bit harder to document so I recreted the issue based off the code located here.

class Test
  require "io/console"
  def self.run
    console_width = IO.console.winsize.last
    ellipsis = '…' # UTF-8 Support only
    string_large_2 = (console_width + 2).times.map { 's' }.join
    string_large_1 = (console_width + 1).times.map { 's' }.join
    string_control = console_width.times.map { 's' }.join
    string_small_1 = (console_width - 1).times.map { 's' }.join
    string_small_2 = (console_width - 2).times.map { 's' }.join

    console_width -= ellipsis.length # remove the ellipsis from the width

    string_large_2.chop! while string_large_2.length > console_width
    string_large_1.chop! while string_large_1.length > console_width
    string_control.chop! while string_control.length > console_width
    string_small_1.chop! while string_small_1.length > console_width
    string_small_2.chop! while string_small_2.length > console_width


    puts '-------------- Results -------------------'
    puts 'string_large_2'
    puts string_large_2 + ellipsis
    puts 'string_large_1'
    puts string_large_1 + ellipsis
    puts 'string_control'
    puts string_control + ellipsis
    puts 'string_small_1'
    puts string_small_1 + ellipsis
    puts 'string_small_2'
    puts string_small_2 + ellipsis
    puts '-------------- End Results ---------------'
  end
end

If you run this in irb it should result in the … breaking to the new line in all the cases except string_small_2, which is under the width of the console.

The solution seam to be that by subtracting one from the lenght on this line https://github.com/mattbrictson/airbrussh/blob/master/lib/airbrussh/console.rb#L46 it will correclty display issues.

Via #24 (comment)

we should replace the use of tail -n 20 with pure ruby, but would need to do something efficient to handle large files. I'm surprised we haven't seen error reports for this for people using windows.

This is referring to Airbrussh::Formatter#on_deploy_failure:

def on_deploy_failure
  return if @log_file.nil?
  err = Airbrussh::Console.new($stderr)
  err.print_line
  err.print_line(red("** DEPLOY FAILED"))
  err.print_line(yellow("** Refer to #{@log_file} for details. "\
                        "Here are the last 20 lines:"))
  err.print_line
  system("tail -n 20 #{@log_file.shellescape} 1>&2")
end

Notice here that "Fetching origin" is printed twice. It only appears once in the actual output when the command is run on the server.

00:05 git:update
      02 git remote update
      02 Fetching origin
      02 Fetching origin

This is probably due to the extra .dup call added in 73ec3e7.

When running against capistrano/sshkit@c840d4f, and when setting airbrussh's command_output=true, sometimes the output that is printed is truncated and strangely formatted.

For example, the Pretty formatter correctly shows the expected output:

 DEBUG [dd068496]   28f6d5b8bc180225ea83bc2f87d3ec4fbe1fe88b    refs/heads/analytical
a0d107abac1f7312c76da7cadd94e471cf29e02e    refs/heads/google-analytics
3405c542e9bf56dbe7b64020c1f7b67185edb589    refs/heads/master
a3cc7a6d62986a085ffd0d27dae85812e335fb25    refs/heads/outdated
43b8fc41129d7afd05e70369d56025b11f07345a    refs/heads/pacific-time
f3b9157c004d3edbc195fef1138f6d680199ff76    refs/heads/sitemap

But the airbrussh console output only shows:

00:01 git:check
      01 git ls-remote --heads [email protected]:user/repo.git
      01 28f6d5b8bc180225ea83bc2f87d3ec4fbe1fe88b refs/heads/analytical
a0d107abac1f7312c76da7cadd94e471cf29e02e  refs…
    ✔ 01 deployer@remote-ip 1.479s

My guess is that output being logged contains newlines which should be split before sending to Console#print_line.

Airbrussh works by hooking into capistrano, and these hooks are currently not integration tested. If capistrano were to change its APIs, there could be a situation where the airbrussh unit tests continue to pass even though it no longer works in practice. Therefore an integration test would be nice to have.

Perhaps the test would create a sample app in a temporary directory with a Gemfile containing capistrano and airbrussh (the latter would point to the version of airbrussh under test using path), then:

• bundle exec cap install STAGES=test
• Add require "airbrussh/capistrano" to the generated Capfile
• Comment out set :format, :pretty in the generated deploy.rb (if necessary)
• Add a sample rake task to deploy.rb that executes something with the local backend
• bundle exec cap test sample_task

Verify that that output is indeed airbrussh-formatted and that cap exited successfully.

Hello, hope you're well.

I used 0.3.0 version of your gem in my projects and everything seemed to be fine, but after upgrade I began to get tons of warnings:

/Users/amikhailov/.rvm/gems/ruby-2.1.5/gems/airbrussh-0.4.0/lib/airbrussh/formatter.rb:230: warning: Capistrano::Configuration::Server::Properties#respond_to?(:marshal_dump) is old fashion which takes only one parameter
/Users/amikhailov/.rvm/gems/ruby-2.1.5/gems/capistrano-3.1.0/lib/capistrano/configuration/server.rb:81: warning: respond_to? is defined here
/Users/amikhailov/.rvm/gems/ruby-2.1.5/gems/airbrussh-0.4.0/lib/airbrussh/formatter.rb:230: warning: Capistrano::Configuration::Server::Properties#respond_to?(:_dump) is old fashion which takes only one parameter
/Users/amikhailov/.rvm/gems/ruby-2.1.5/gems/capistrano-3.1.0/lib/capistrano/configuration/server.rb:81: warning: respond_to? is defined here

After digging into a code I've found out that these warnings are generated by this method in Airbrussh::Formatter:

    def deep_copy(obj)
      Marshal.load(Marshal.dump(obj))
    end

After that I've looked into Capistrano code:

        def respond_to?(method)
          @properties.has_key?(method)
        end

Obviously, these warnings come from old Capistrano which is not suited well to new ruby. I'm not certain if they fixed this in newer versions however. Nevertheless I cannot upgrade to newer Capistrano at this moment (capistrano comes as dependency of internal gem).

I know it is not your fault but maybe there is another way to implement deep_copy stuff having in mind some legacy code (like old capistrano, for instance)?

Hi,

When using capistrano/npm it shows a really addinfinitum log like this:

00:13 npm:install 01 npm install --production --silent --no-progress 01 - 01 \ 01 | 01 / 01 - 01 \ 01 | 01 / 01 - 01 \ 01 | 01 / 01 - 01 \ 01 | 01 / 01 - 01 \
[...]
01 \ 01 | 01 / 01 - 01 [email protected] node_modules/expose-loader 01 01 [email protected] node_modules/mirror-creator 01 01 [email protected] node_modules/babel 01 01 [email protected] node_modules/react-dom

the log part with the packages installed is fine but the spinning cog are like 100 lines or more and is sad :(

Regards,
juanma

IO.console could be also nil if Ruby executable is called through a sudo su - user -c '~/.rvm/bin/rvm 2.3.1 do ruby -e -e "require %{io/console}; puts IO.console.winsize"' construction. It should be nil-checked anyway.

(To be honest in this case @output.tty? either should not be true (indicating the output is not a tty) or IO.console should be a valid TTY console, so this is a bug in MRI Ruby anyway, but should be workarounded as Ruby development and upgrading shipped versions in Linux distributions is much slower than any Gem development)

Example outputs:

$  sudo su - app -c 'cd /deploy/ && /home/app/.rvm/bin/rvm ruby-2.3.1@default do ruby -e "require %{io/console}; puts IO.console.winsize"'
-e:1:in `<main>': undefined method `winsize' for nil:NilClass (NoMethodError)

$ /home/app/.rvm/bin/rvm ruby-2.3.1@default do ruby -e "require %{io/console}; puts IO.console.winsize"
55
211
$ 

My hack was adding and IO.console to the end of this line, but I am not sure it should be a right fix. It just provided me a working Capistrano run and I wasn't interested more in the solution.

I'm not sure if this was intentional, but this change:

group :extras, :optional => true

Caused my call to rake to fail like this:

airbrussh:rake
There was an error in your Gemfile, and Bundler cannot continue.

I tried bundle install and I got this:

bundle install
/Users/robd/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/bundler-1.9.4/lib/bundler/dependency.rb:54:in `block in initialize': undefined method `to_sym' for {:optional=>true}:Hash (NoMethodError)

Basically, looks like :optional => true is not backwards compatible with older versions of bundler. I'm not sure if this was intentional - looks like the intention was for v1.10 of bundler to only be needed for people who wanted to run the optional tasks, but this doesn't work - everyone needs v1.10.

I upgraded bundler, reinstalled the gems and then I saw:

airbrussh:rake                                                                                                                                                                        2.2.2
rake aborted!
LoadError: cannot load such file -- chandler/tasks
/Users/robd/dev/airbrussh/Rakefile:14:in `require'

This can be fixed by patching the rake file like this, (but I don't know what gem version find_all_by_name was added):

if !ENV["TRAVIS"] &&  Gem::Specification::find_all_by_name('chandler').any?
  require "chandler/tasks"
  task "release:rubygem_push" => "chandler:push"
end

I'm not sure what the motivation was as far as making some gems optional. I think it is a nice idea in principle, but I wonder if the complexity of trying to make them optional is worth it. Personally I'm happy to just install everything even if I don't use guard, chandler etc.

I'm happy to do a PR for this, but I wanted to discuss first to find out which direction it should go in.

Hi,

when i installed airbrussh, my cap production deploy ends with trace below.

I tried to add #encoding: utf-8 into "deploy.rb", or add to LANG="en_US.UTF-8" and LC_ALL="en_US.UTF-8" into "Gemfile", but it doesn't help.

Thank you for your suggestions, how to fix it.

cap aborted!
ArgumentError: invalid byte sequence in US-ASCII
/usr/lib64/ruby/gems/1.9.1/gems/rake-10.4.2/lib/rake/trace_output.rb:16:in `block in trace_on'
/usr/lib64/ruby/gems/1.9.1/gems/rake-10.4.2/lib/rake/trace_output.rb:14:in `map'
/usr/lib64/ruby/gems/1.9.1/gems/rake-10.4.2/lib/rake/trace_output.rb:14:in `trace_on'
/usr/lib64/ruby/gems/1.9.1/gems/rake-10.4.2/lib/rake/application.rb:376:in `trace'
/usr/lib64/ruby/gems/1.9.1/gems/rake-10.4.2/lib/rake/application.rb:222:in `display_exception_message_details'
/usr/lib64/ruby/gems/1.9.1/gems/rake-10.4.2/lib/rake/application.rb:209:in `display_exception_details'
/usr/lib64/ruby/gems/1.9.1/gems/rake-10.4.2/lib/rake/application.rb:198:in `display_error_message'
/usr/local/lib64/ruby/gems/1.9.1/gems/capistrano-3.4.0/lib/capistrano/application.rb:73:in `display_error_message'
/usr/lib64/ruby/gems/1.9.1/gems/rake-10.4.2/lib/rake/application.rb:185:in `rescue in standard_exception_handling'
/usr/lib64/ruby/gems/1.9.1/gems/rake-10.4.2/lib/rake/application.rb:176:in `standard_exception_handling'
/usr/lib64/ruby/gems/1.9.1/gems/rake-10.4.2/lib/rake/application.rb:93:in `load_rakefile'
/usr/lib64/ruby/gems/1.9.1/gems/rake-10.4.2/lib/rake/application.rb:77:in `block in run'
/usr/lib64/ruby/gems/1.9.1/gems/rake-10.4.2/lib/rake/application.rb:176:in `standard_exception_handling'
/usr/lib64/ruby/gems/1.9.1/gems/rake-10.4.2/lib/rake/application.rb:75:in `run'
/usr/local/lib64/ruby/gems/1.9.1/gems/capistrano-3.4.0/lib/capistrano/application.rb:15:in `run'
/usr/local/lib64/ruby/gems/1.9.1/gems/capistrano-3.4.0/bin/cap:3:in `<top (required)>'
/usr/local/bin/cap:23:in `load'
/usr/local/bin/cap:23:in `<main>'

Loving the extension, but unfortunately i had to deactivate it because the nice formatting kills one capistrano task i use often.

I usuall have a task to tail logs on the server, like so (maybe also for other log types):

desc 'Logs'
task :logs do
  on roles(:app) do
    execute "tail -f #{fetch(:deploy_to)}/shared/log/#{fetch(:rails_env)}.log"
  end
end

Which is a very simple way to help debugging issues on a server environment. Unfortunately it also uses the pretty formatting and thus not giving any output anymore.

I could not find any way of turning formatting of for just a single task. Maybe i missed it, otherwise i think it would be a great addition, not only so i can turn the whole airbrussh on again :)

I'm getting this error in JRuby

cap aborted!
NoMethodError: undefined method `open?' for #<File:/dev/tty>
/usr/local/rbenv/versions/jruby-9.0.0.0/lib/ruby/stdlib/io/console.rb:159:in `console'
/usr/local/rbenv/versions/jruby-9.0.0.0/lib/ruby/gems/shared/gems/airbrussh-0.5.1/lib/airbrussh/console.rb:59:in `console_width'
/usr/local/rbenv/versions/jruby-9.0.0.0/lib/ruby/gems/shared/gems/airbrussh-0.5.1/lib/airbrussh/console.rb:42:in `truncate_to_console_width'
/usr/local/rbenv/versions/jruby-9.0.0.0/lib/ruby/gems/shared/gems/airbrussh-0.5.1/lib/airbrussh/console.rb:26:in `print_line'
/usr/local/rbenv/versions/jruby-9.0.0.0/lib/ruby/gems/shared/gems/airbrussh-0.5.1/lib/airbrussh/formatter.rb:174:in `print_line'
/usr/local/rbenv/versions/jruby-9.0.0.0/lib/ruby/gems/shared/gems/airbrussh-0.5.1/lib/airbrussh/formatter.rb:42:in `write_banner'
/usr/local/rbenv/versions/jruby-9.0.0.0/lib/ruby/gems/shared/gems/airbrussh-0.5.1/lib/airbrussh/formatter.rb:28:in `initialize'
/usr/local/rbenv/versions/jruby-9.0.0.0/lib/ruby/gems/shared/gems/sshkit-1.7.1/lib/sshkit/configuration.rb:48:in `block in formatter'

When last revision SHA of last deployment and current deployment happens to be same. I received the following error message:

fatal: ambiguous argument '8849c9b..8849c9b': unknown revision or path not in the working tree. Use '--' to separate paths from revisions