7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
|
# File 'lib/aptible/cli/subcommands/ssh.rb', line 7
def self.included(thor)
thor.class_eval do
include Helpers::Operation
include Helpers::App
desc 'ssh [COMMAND]', 'Run a command against an app'
long_desc " Runs an interactive command against a remote Aptible app\n\n If specifying an app, invoke via: aptible ssh [--app=APP] COMMAND\n LONGDESC\n app_options\n option :force_tty, type: :boolean\n def ssh(*args)\n app = ensure_app(options)\n\n # SSH's default behavior is as follows:\n #\n # - If a TTY is forced, one is allocated.\n # - If there is no command, then a TTY is allocated.\n # - If no-TTY is forced, then none is allocated.\n # - No TTY is allocated if stdin isn't a TTY.\n #\n # Unfortunately, in our case, this breaks, because we use a\n # forced-command, so we don't *ever* send a command, which causes\n # SSH to *always* allocate TTY, which causes a variety of\n # problems, not least of which is that stdout and stderr end up\n # merged.\n #\n # Now, it's pretty common for Aptible users to run commands in\n # their container with the intention of using a TTY (by e.g.\n # running `aptible ssh bash`), so we use a slightly different\n # heuristic from SSH: we allocate TTY iif there's no input or\n # output redirection going on.\n #\n # End users can always override this behavior with the\n # --force-tty option.\n tty_mode, interactive = if options[:force_tty]\n ['-tt', true]\n elsif [STDIN, STDOUT].all?(&:tty?)\n ['-t', true]\n else\n ['-T', false]\n end\n\n op = app.create_operation!(\n type: 'execute',\n command: command_from_args(*args),\n interactive: interactive\n )\n\n ENV['ACCESS_TOKEN'] = fetch_token\n opts = ['-o', 'SendEnv=ACCESS_TOKEN', tty_mode]\n exit_with_ssh_portal(op, *opts)\n end\n\n private\n\n def command_from_args(*args)\n args.empty? ? '/bin/bash' : Shellwords.join(args)\n end\n end\nend\n"
|