Live data from Hacker News

Launch a Debugging Terminal into GitHub Actions

blog.gripdev.xyz

11–20 of 67 posts

Re: Launch a Debugging Terminal into GitHub Actions

#11

There are many tools and techniques like this. Not a nock against this tool, just an observation that we seemingly need these tools. Is there no better way, GitHub?

> Is there no better way, GitHub?

CircleCI solved this anno 2011, with "Rebuild with SSH". Microsoft asleep at the wheel as usual, not sure it's unexpected at this point.

Re: Launch a Debugging Terminal into GitHub Actions

#13
post #8

I'm using tmate for this: https://github.com/mxschmitt/action-tmate

This is the only reasonable way to ever do this, requires no effort, just copy paste one of the examples and you're done. My only gripe is that the most secure option isn't the first example in the repo. Limit access to the actor and put it behind the debug only flag and you're good to go. Still, I remove it after the fact once I don't need it anymore since it feels a bit too sketch with secrets available.

Re: Launch a Debugging Terminal into GitHub Actions

#14

That'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

This kind of misses the point, though. I would say a much better rule is whatever runs in your workflows should also be entirely reproducible locally.

Even if you can ssh into the remote environment that does not cover things like authentication and authorization, you don't just git a GITHUB_TOKEN with the same permissions.

Re: Launch a Debugging Terminal into GitHub Actions

#17

There are many tools and techniques like this. Not a nock against this tool, just an observation that we seemingly need these tools. Is there no better way, GitHub?

> Is there no better way, GitHub? CircleCI solved this anno 2011, with "Rebuild with SSH". Microsoft asleep at the wheel as usual, not sure it's unexpected at this point.

The more you have to rerun your actions to debug them, the more money Microsoft makes. They aren’t incentivized to save you time.

Re: Launch a Debugging Terminal into GitHub Actions

#18

That 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 am surprised Docker didn't launch into the CI market. Running a container build as CI seems like it would both be a boon for simplifying CI caching and also debugging since it's ~reproducible locally.

Re: Launch a Debugging Terminal into GitHub Actions

#19

That'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-images/issues/176

Post reply on HN