Conversation
|
Is this something you have observed in practice? |
Yes, this had reportedly happend in some scenarios. Although, now, on second thought, I doubt it since the discovery is the only persistent runner and it regularly would not set up a ssh connection to itself. Workers are regularly not persistent so they shouldn't suffer from dangling ssh agents. Only in the scenario that a worker is serviced by a hosted runner can those be left dangling. @michalrus do you happen to have more context on what we had observed, in this context? |
I don’t think this is the case, since if an
Yes, so we’re using NixOS on the discovery host, and the standard GitHub Runner service ( We’re not setting the So the But now that I think of it, I could just set |
michalrus
left a comment
There was a problem hiding this comment.
If it works, then it’s looking good =) Thanks!
| # Auth agent socket to ssh config | ||
| echo "IdentityAgent $SSH_AUTH_SOCK" >> "$SSH_CONFIG_FILE" | ||
| # Save pid to cleanup in post step | ||
| echo "SSH_AGENT_PID=$SSH_AGENT_PID" >> "$GITHUB_STATE" |
There was a problem hiding this comment.
So later GHA export that automatically?
Context
The ssh connection to a discovery host leaves a dangling ssh agent.
If the workflow runner itself runs on a persistent runner, that process might just accumulate.
Solution
Clean up after ourselves. Unfortunately, only js actions allow to trigger a post action which is why a slight refactor needed to be done to wrap the bash action inside a js action.