I'm using tmate for this: https://github.com/mxschmitt/action-tmate
tmate.io returns a 503. Hugged to death by your comment?
Launch a Debugging Terminal into GitHub Actions
31–40 of 67 posts
Re: Launch a Debugging Terminal into GitHub Actions
#32That the entire ecosystem seems to have moved to GitHub Actions is such a loss for productivity. I remember when CircleCI first launched, and you could "Rebuild with SSH" which gave you a bash command to connect to the running instance whenever you wanted, was such a no-brainer, and I'm sure why many of us ended up using CircleCI for years. Eventually CircleCI became too expensive, but I still thought that if other s…
I've gotten used to this essential feature too via Semaphore CI, and I just can't stand not being able to SSH into a GitHub Action. Debugging is so slow.
Re: Launch a Debugging Terminal into GitHub Actions
#33I solved it by adding a simple Tailscale action to handle failure. It creates an ephemeral instance and waits for connections for 3 minutes. Then it loops while there's an active SSH session present.
It's that simple: https://gist.github.com/Cyberax/9edbde51380bf7e1b298245464a2... and it saved me _hours_ of debug time.
I've moved all my CI/CD to use Taskfiles inside a Docker container since then, so my local environment can replicate the CI/CD environment up to the GITHUB_TOKEN. Still, being able to poke around Github builders is great.
Re: Launch a Debugging Terminal into GitHub Actions
#34Earlier quoted context omitted.
> That's my hill to die on : you must have a self hosted agent. That’s only true if you’re building simple workflows. A counter-example would be a workflow that builds and uploads Android APKs. When I last checked last year, there weren't any well-maintained Docker images with the Android SDK pre-installed, and there are no updated, publicly available builds for the runner-images: https://github.com/actions/runner-im…
I do not follow. How does that change anything? Don't things still go wrong? Do you not need to debug?
Sorry for not being clearly enough.
The point is that it is very difficult to replicate the environment of a hosted GitHub Actions runner, and having to do so defeats the ease of use the platform provides.
Re: Launch a Debugging Terminal into GitHub Actions
#35I want this for Gitlab so badly
GitLab already has "interactive web terminals" which is basically the same thing: https://docs.gitlab.com/ci/interactive_web_terminal/
Re: Launch a Debugging Terminal into GitHub Actions
#36Why SSH to the build agent when you can run your actions locally using the excellent https://github.com/nektos/act
Re: Launch a Debugging Terminal into GitHub Actions
#37I'm using tmate for this: https://github.com/mxschmitt/action-tmate
I have written https://github.com/efrecon/sshd-cloudflared to solve the same problem. It provides you with an SSH connection inside a transient cloudflare tunnel. The connection is only accessible to the SSH public keys stored in your GitHub account.
Re: Launch a Debugging Terminal into GitHub Actions
#38That's my hill to die on : you must have a self hosted agent. You can have many cloud agents as you wish but you must at least have one where you can remotely connect. It has saved me hours of troubleshooting and polluting "workflow v1.3.56_final_should_work_2" commits
> That's my hill to die on : you must have a self hosted agent. That’s only true if you’re building simple workflows. A counter-example would be a workflow that builds and uploads Android APKs. When I last checked last year, there weren't any well-maintained Docker images with the Android SDK pre-installed, and there are no updated, publicly available builds for the runner-images: https://github.com/actions/runner-im…
I'm building and deploying appbundle from my self hosted runner for this exact reason.
I manually maintain flutter and Android sdk on my server.
I've never been a docker fan, I prefer to completely handle my whole stack.
I have scripts to install the required tools and some actions in my scripts are just echoing what needs to be done manually.
With the years, I've found that infra for fully reproducible builds cost too much to maintain for us.
Re: Launch a Debugging Terminal into GitHub Actions
#39That the entire ecosystem seems to have moved to GitHub Actions is such a loss for productivity. I remember when CircleCI first launched, and you could "Rebuild with SSH" which gave you a bash command to connect to the running instance whenever you wanted, was such a no-brainer, and I'm sure why many of us ended up using CircleCI for years. Eventually CircleCI became too expensive, but I still thought that if other s…
Still using CircleCI. I do not love YAML at all, in fact I hate it because it's basically a 1980s text preprocessor on steroids and with dependency management. Too much logic applied to config that depends on implicit syntax and unintuitive significant whitespace. I mean, I had an issue once where this broke the pipeline: key: - value 1 - value 2 But this was fine: key: - value 1 - value 2 Fuck that noise! Otherwise…
> I mean, I had an issue once where this broke the pipeline:
It seems fair to dislike YAML (I dislike it too), but I don't understand how this broke for you unless CircleCI (or whoever) isn't actually using a legal YAML parser.
irb(main):009:0> YAML.load {"key"=>["value 1", "value 2"]}
irb(main):014:0> YAML.load {"key"=>["value 1", "value 2"]}
Re: Launch a Debugging Terminal into GitHub Actions
#40That the entire ecosystem seems to have moved to GitHub Actions is such a loss for productivity. I remember when CircleCI first launched, and you could "Rebuild with SSH" which gave you a bash command to connect to the running instance whenever you wanted, was such a no-brainer, and I'm sure why many of us ended up using CircleCI for years. Eventually CircleCI became too expensive, but I still thought that if other s…
I've gotten used to this essential feature too via Semaphore CI, and I just can't stand not being able to SSH into a GitHub Action. Debugging is so slow.
I've seen people spend something like 2 hours fixing something that can be fixed in minutes if you had a normal feedback cycle instead of the 5 minute "change > commit > push > wait > see results" feedback cycle GitHub Action forces people into. It's baffling until you realize Microsoft charges per usage, so why fix it? I guess the baffling part is how developers put up with it anyways.