Open eine opened 4 years ago
This is essential for https://github.com/pear/Crypt_GPG. Right now I can not test GnuPG v2. It was working with Travis.
On bash I can force TTY with the following hack
shell: 'script --return --quiet --command "bash {0}"'
run: |
<command requiring TTY>
@dakale @joshmgross @bryanmacfarlane
On the off chance it helps make the case for re-prioritizing: this is continually externalizing work on users and maintainers.
Every person/team/project that encounters this has to burn time (and, often, GH computational resources) on some combination of:
Once this cascades over into issues filed on other tools/projects, the developers of those projects also have to burn time understanding the issue, deciding whether it's right for them to address it, and implementing something.
Without a fix, all of these remain ongoing costs.
It's been over three years now, and this is still an ongoing issue. We shouldn't need hack workarounds just for Bash in order to make programs think there's a tty. With that said, I hope we see some progress baked into GHA soon.
I just made a workaround that should eliminate the Not a TTY problem on all platforms every time. However, it involves modifying the underlying code to check for an environment variable that overrides any false isatty checks. Here's an implementation of it in C++: https://github.com/Slackadays/Clipboard/commit/d80c6b380242ae52d876edee8500bd4bf944ce0c
This issue is messing with my tests again, and it's getting so annoying to have not one or two but three manual workarounds to think about when writing new ones (one is the mechanism inside the project, two is the invocation of this mechanism, three is specifying a custom action due to first workaround)
I just made a workaround that should eliminate the Not a TTY problem on all platforms every time. However, it involves modifying the underlying code to check for an environment variable that overrides any false isatty checks. Here's an implementation of it in C++: Slackadays/Clipboard@d80c6b3
please dont state this as a "workaround"
your version simply "pretends" it is a tty when infact it is not an actual tty
please dont state this as a "workaround"
your version simply "pretends" it is a tty when infact it is not an actual tty
That's literally what a workaround is
Still, pretending to be a tty is probably not a good thing :3
On Sat, 2 Dec 2023, 11:06 pm Jackson Huff, @.***> wrote:
please dont state this as a "workaround"
your version simply "pretends" it is a tty when infact it is not an actual tty
That's literally what a workaround is
— Reply to this email directly, view it on GitHub https://github.com/actions/runner/issues/241#issuecomment-1837144504, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGLITH6MIE75ET4IMBJ27CTYHMRUNAVCNFSM4J5K766KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBTG4YTINBVGA2A . You are receiving this because you commented.Message ID: @.***>
This seems like the workaround I need, based on https://github.com/actions/runner/issues/241#issuecomment-842566950 by adding defaults.run.shell
in the workflow file.
# SEE UPDATE BELOW
defaults:
run:
# GitHub Actions run without a TTY device. This is a workaround to get one,
# based on https://github.com/actions/runner/issues/241#issuecomment-842566950.
shell: 'script -q -e -c "bash --noprofile --norc -eo pipefail {0}"'
When shell
isn't specified on Linux/Mac, the default is not bash --noprofile --norc -eo pipefail {0}"
, but rather bash -e {0}
.
Also, without specifying --log-out /dev/null
we get a file created called typescript with the stdout output I think.
Due to that, the minimal change to get a TTY should be this I think:
defaults:
run:
# GitHub Actions run without a TTY device. This is a workaround to get one,
# based on https://github.com/actions/runner/issues/241#issuecomment-2019042651
shell: 'script --return --quiet --log-out /dev/null --command "bash -e {0}"'
macOS-based runners use the BSD version of the script
command, which accepts different command-line options to those suggested in @consideRatio's suggestion. Instead, the following should work (tested on macos-11
, macos-12
, macos-13
, and macos-14
runners):
shell: 'script -q /dev/null bash -e {0}'
n.b. bash -e {0}
should not be quoted, or it will be treated as a single argument and cause the step to fail with a No such file or directory
error.
Default shells seem to be limited. For example, the following step:
produces:
As a result, multiple tools that can provide pretty coloured logs do not work as expected. This is the case of e.g. colorama or pytest in the Python ecosystem.
A possible workaround is to use
docker run --rm -t ...
. However, this involves installing in the container multiple resources/tools that are already available on the host. Furthermore, I don't know if windows containers are supported onwindows-latest
jobs.I tried setting
shell: bash -i -l {0}
, but I get:I tried
python -c 'import pty; pty.spawn("/bin/sh")'
too, but the job wil run for more than 10min with no output.Which is the appropriate syntax to get a TTY?