One of the most annoying things when debugging, especially when debugging things that trigger an ‘exit’ somewhere: You walk carefully through your steps, eventually reaching the point of the command that has some issue. You modify the command to enable whatever debugging you can get. You run it, it 'exit’s, and BAM! – Console cleared, “[lost server]” and the connection to the debug build is gone.
Please remove the .bash_logout, and whatever else is clearing the console, please!
If you’re stuck here, btw: What works is to capture the complete debug session through script(1). The output file will be intermixed with control characters, but it should allow to at least read the output before the window cleared.
exit is not recommended for use because it doesn’t terminate the build gracefully.
Instead, place user commands that must not fail into the install: stage: failure of any of them terminates the build after that command returns and marks the build “errored”.
If you need to quit from some Bash code early, you can run it in a subshell (<commands>) or a script file so that an exit would only terminate the subprocess rather than the main shell process.
For your purpose, you can override exit with a Bash function before debugging:
I guess I wasn’t clear: I’m talking about scripts already, i.e. actual files executed through a shell.
Thanks. I’ll try to remember this as another option.
The specific case I was debugging now was actually the dpl (v1) tool from what I see, which failed because it couldn’t find the script I told it to use. dpl had a point, the script indeed was missing due to the use of git stash --all – ultimately solved with a skip_cleanup: true.
I’m still considering “travis debug shells clear themselves out when exiting” a bug – usually I’d file that in some issue tracker, but as that one is gone: What’s the process?
Set the script value to “something-that-doesnt-exist”
Run the build, it should fail
Debug the build, and execute travis_run_{setup,before_install,install,before_script,script,after_success}
(In reality the something-that-doesnt-exist did exist, but got stashed away just before dpl got ran. Shouldn’t make a difference :D)
If this shouldn’t exit the debug build, then that’s another bug. If you try to reproduce it, and it doesn’t exit the build, then I can go ahead and try to reduce my actual build setup to a shareable minimum.
OK, so I have worked out a series of tmate commands that will achieve what you are asking. I looked into ways to make it easier on the user, but I have been (so far, at any rate) unsuccessful.
Here are the steps:
Start a debug build, and connect to it.
In the session, turn on the remain-on-exit option for this window:
tmate -S /tmp/tmate.sock set-option -t 0 remain-on-exit on
Do your thing in this window, and when you’re done, exit. This will leave your session output in place, but the window is now unresponsive. You can now copy your output from the window (Ctrl-b, [, and arrow keys to scroll, if desired).
Open a new window to this session by Ctrl-b, followed by c.
In the new window, kill the first window that got “stuck”:
tmate -S /tmp/tmate.sock kill-window 0
exit from the new window. The ssh session will now close and the debug build will finish.
Maybe we can define a bash function or something to reduce the amount of typing here and there, but the mechanics of this seems to be rather rigid.