Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch a Debugging Terminal into GitHub Actions

blog.gripdev.xyz

Post reply on HN
Print view View original

41–50 of 67 posts

Re: Launch a Debugging Terminal into GitHub Actions

#41

Post by jborean93 »

ljm wrote: post #29
embedding-shape wrote: post #10

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…

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…

There shouldn't be any difference between those two values. I'm not saying you are wrong and it didn't break but it's definitely surprising a parser would choke on that vs YAML itself being the problem.

Don't get me wrong I can empathise with whitespace formatting being annoying and having both forms be valid just adds confusion it's just surprising to see this was the problem.

Re: Launch a Debugging Terminal into GitHub Actions

#43

Post by Storment33 »

embedding-shape wrote: post #40
fyhn wrote: post #32

Earlier quoted context omitted.

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.

Does not sound like a GitHub failure, sounds it is the company's failure. They haven't invested in the developer experience and they have developers who cannot run stuff locally and are having to push to CI in order to get feedback.

Re: Launch a Debugging Terminal into GitHub Actions

#44

Post by Storment33 »

flanked-evergl wrote: post #14
whynotmaybe wrote: post #4

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.

Exactly, you should be able to do everything locally! All this needing to SSH into runners or needing self-hosted runners or needing act to emulate GitHub Actions is really a failure of the developer experience.

Re: Launch a Debugging Terminal into GitHub Actions

#45

Post by Storment33 »

esafak wrote: post #23
baby_souffle wrote: post #6

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?

Dagger. Workflows that run anywhere, including locally.

I've seen dagger pipelines they're horrendous. Just have GitHub Actions call out to a task runner like Make/Taskfile etc and use an environment manager Mise or Nix to install all the tools.

Re: Launch a Debugging Terminal into GitHub Actions

#46

Post by embedding-shape »

Storment33 wrote: post #43
embedding-shape wrote: post #40

Earlier quoted context omitted.

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.

Does not sound like a GitHub failure, sounds it is the company's failure. They haven't invested in the developer experience and they have developers who cannot run stuff locally and are having to push to CI in order to get feedback.

Can't do much about that when there is something you're troubleshooting about the CI platform itself. Say you're troubleshooting why the deployment doesn't work, somehow got the environment variable wrong for whatever reason. So you edit and add a "env | sort" before that, commit it, push it, so on. With "rebuilt with ssh", you literally are inside the "job" as it runs.

Re: Launch a Debugging Terminal into GitHub Actions

#47

Post by Storment33 »

embedding-shape wrote: post #46
Storment33 wrote: post #43

Earlier quoted context omitted.

Does not sound like a GitHub failure, sounds it is the company's failure. They haven't invested in the developer experience and they have developers who cannot run stuff locally and are having to push to CI in order to get feedback.

Can't do much about that when there is something you're troubleshooting about the CI platform itself. Say you're troubleshooting why the deployment doesn't work, somehow got the environment variable wrong for whatever reason. So you edit and add a "env | sort" before that, commit it, push it, so on. With "rebuilt with ssh", you literally are inside the "job" as it runs.

Yes you can't really debug CI specific stuff locally, like if your setting up build caching or something. But it seems like 90%+ of the time people are complaining about builds/tests that should have local feedback loops.

Re: Launch a Debugging Terminal into GitHub Actions

#48

Post by embedding-shape »

Storment33 wrote: post #47
embedding-shape wrote: post #46

Earlier quoted context omitted.

Can't do much about that when there is something you're troubleshooting about the CI platform itself. Say you're troubleshooting why the deployment doesn't work, somehow got the environment variable wrong for whatever reason. So you edit and add a "env | sort" before that, commit it, push it, so on. With "rebuilt with ssh", you literally are inside the "job" as it runs.

Yes you can't really debug CI specific stuff locally, like if your setting up build caching or something. But it seems like 90%+ of the time people are complaining about builds/tests that should have local feedback loops.

Yeah, fair point, I see that a lot in the wild too. I guess I kind of assumed we all here had internalized the practice of isolating everything into one command that runs remotely, like "make test" or whatever, rather than what some people do and put entire shellscripts-but-yaml in their pipeline configs.

Re: Launch a Debugging Terminal into GitHub Actions

#49

Post by whynotmaybe »

Storment33 wrote: post #44
flanked-evergl wrote: post #14

Earlier quoted context omitted.

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.

Exactly, you should be able to do everything locally! All this needing to SSH into runners or needing self-hosted runners or needing act to emulate GitHub Actions is really a failure of the developer experience.

A lot of stuff can be handled by developer themselves, but usually some steps are voluntarily blocked, like publishing to Google Play/App store.

You don't want anyone to be able to publish public facing app from their version of the code that might not be committed.

Some of us remember an era where deployment was copy-paste from the local /bin folder to the /bin folder on production server.

Re: Launch a Debugging Terminal into GitHub Actions

#50

Post by Storment33 »

whynotmaybe wrote: post #49
Storment33 wrote: post #44

Earlier quoted context omitted.

Exactly, you should be able to do everything locally! All this needing to SSH into runners or needing self-hosted runners or needing act to emulate GitHub Actions is really a failure of the developer experience.

A lot of stuff can be handled by developer themselves, but usually some steps are voluntarily blocked, like publishing to Google Play/App store. You don't want anyone to be able to publish public facing app from their version of the code that might not be committed. Some of us remember an era where deployment was copy-paste from the local /bin folder to the /bin folder on production server.

While I get some stuff you can't test locally, like 90%+ of complaints I see are for builds/tests. Which is really a failure of the engineers for not having a local feedback loop.

I am of the opinion you should be able to deploy from your machine, just you do not have the permissions to normally. So that if CI ever goes down and you need to push an emergency fix or something you can break glass if needed.

Post reply on HN