-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
too hard to notice cap failure in terminal, because log lines push actual error off screen #2022
Comments
Absolutely agreed this can suck, especially in the context of limited scrollback buffers or people who use tmux with unreliable mouse scrolling where you need 5 key presses to get to a scrollback mode. I'm not actually sure about being able to turn off the last 20 lines repeated, I guess that code was written 5-6 years ago and hasn't been touched meaningfully since, lemme look into it... |
I found the responsible code in the airbrussh gem, it threw me because the output you pasted is not airbrussh format output but our native "pretty" format. Airbrussh is reading the log file from disk and forwarding the contents which explains why. The offending code is at https://github.com/mattbrictson/airbrussh/blob/eac9bbe3fbf0990cf655746c36a9ba4e1c47950d/lib/airbrussh/capistrano/tasks.rb#L37-L48 and I can't see an obvious way to change its behaviour, that said, it does appear to simply hook Alternatively don't use the airbrussh formatter, and set the output printer to the :pretty one. Matt is on hiatus right now so I don't think we can count much on his engagement, but I'd be more than willing to help you shepherd a patch through airbrussh to get that to be configurable. We currently have a line of configuration options for airbrussh (optionally) in the deploy.rb template, here:
|
Hmm, I haven't heard of The simplest fix initially seemed to be just having cap output I may try the But if the current behaior, using |
Okay, looking into it more I see @leehambley I guess this isn't your gem, but do you have commit rights to it? airbrussh? The simplest thing that I think would provide a better experience for what is the default capistrano formatter -- what if it just swapped the order of the output? Put the "last 20 log lines" output first, and the line 43 |
It's also kind of a mystery why the |
Airbrussh is actually Matt's gem, he wrote it to have nicer, prettier output and a few years ago we changed it to be the default formatter in newly generated Capfiles in the initialization template.
I think that'd be totally reasonable, I'd recommend opening an issue against Airbrussh, it should be trivial, though beware there are specs for the output handling (🎉 ) which should make testing this a bit easier for you. Regarding the double newlines, I'm also not sure, maybe it'd be worth chomping the lines read from the file before doing anything with them? WDYT? |
Here is an error I just got on a cap deploy:
"DEPLOY FAILED" is in red, and "Refer to log/capistrano.log..." is in yellow... but neither are actually in my terminal window, they've scrolled out of the current terminal view, because of the 20 log lines appended to them. (Yes, the intermediate newlines between log lines are ther ein my output too, which doesn't help, but even without them I think it would make the failure notice too easy to miss).
** DEPLOY FAILED
message be REPEATED after the log lines?Even if configurable to be different, I think this is not a great experience for newbies. It's too easy to run a cap deploy and think it ran successfully, when it failed. Especially because a typical cap deploy has so much logging already, the repeated "last 20 lines" just look like more of it, unless you know what the terminal output should end with, and realize it's not there, or think to scroll back to look for an error message... it is far too easy to not realize your deploy failed.
The text was updated successfully, but these errors were encountered: