Replies: 4 comments
-
Hello @kousu , I have login to VM that was generated based on this repository (exact same VM that we deploy to Hosted pools) and everything works as expected on that VM. It took less than seconds to run: Then I have installed runner to VM and added this machine as self-hosted to my GitHub repo. And added simple YAML: name: CI
on:
push:
workflow_dispatch:
jobs:
build:
runs-on: self-hosted
steps:
- name: Run a one-line script
run: |
yes | head -n 7 I think the issue comes from https://github.com/actions/runner because I have confirmed above that VM itself doesn't have such issue. |
Beta Was this translation helpful? Give feedback.
-
One more interesting thing is that I can't reproduce it on Azure DevOps. |
Beta Was this translation helpful? Give feedback.
-
Wow, thanks for being as thorough as you could, and on the holidays no less. Not seeing it on Azure seals the deal for me I think. I'll go file this with https://github.com/actions/runner and wait for someone with more experience to have time to devote to it. Happy holidays! 🌴 🎋 🎄 🌳 🌲 |
Beta Was this translation helpful? Give feedback.
-
Locking this convo since the issue is related to the runner, not the image |
Beta Was this translation helpful? Give feedback.
-
In several scripts I help maintain we use
yes | something
in order to makesomething
non-interactive; I I know it's not good modern practice but it's there and I have to deal with it for the time being.I've been porting our CI to Actions and discovered that this construction fails on
macos-latest
. It's really bizarre.something
will run to completion but then the job will hang indefinitely.Example
I've made a minimal test case here: https://github.com/kousu/hanging-actions/. It basically just tests:
plus collecting some context for debugging.
The symptom is that the Linux builds finish immediately while the macOS build hangs in yellow forever:
For example, on this Actions Workflow and this this Travis script for comparison, everything finishes in about a minute except for Actions-macOS.
This should only take a moment; e.g. on Travis, 20s:
but on Actions it's at 3 minutes and counting:
Debugging
I've figured out enough to guess that
yes
is refusing to quit even thoughhead
has closed its stdin. But why?diffing the logs
Travis and Actions use slightly different log formats -- and they set
$PS4
differently and have different ideas about when to use\r
s -- but we can clean that all up with shell gunk:(
Intermediates, for orienting yourself if you take a look; there's a lot of output!:
)
full diff
(- is Travis, + is Actions here)
Points in this diff that stand out to me:
yes
is refusing to die like I thought:TERM=dumb
set? As in, notTERM=xterm
like Travis.TERM
often messes up interactive scripts, but I don't see why that would affectyes
, it's too simple.LC_CTYPE=en_US.UTF-8
set? But again, why would that matter?theories
Maybe Github's runner is doing something bizarre with hooking stdout of every subprocess and failing to pass along the broken pipe error to
yes
?Workarounds
I can solve most of this by switching to use flags like
NONINTERACTIVE=1
forbrew
,apt-get -y
,yum -y
,pacman --noconfirm
. But it's really bugging me that there's something weird I don't understand about pipes on this specific runner. I'd like to understand!By the way, I'm a bit unclear if this is the right forum for this. If there's somewhere better I should be directing this please help me find it and I'll totter over there.
Thanks in advance for any insight. I thought I was pretty good with pipes and fds and weird unix corners but this one has me stumped.
Beta Was this translation helpful? Give feedback.
All reactions