51–60 of 67 posts
Earlier quoted context omitted.
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.
Dagger used to be more declarative with CUE, but demand was not strong enough.
Why SSH to the build agent when you can run your actions locally using the excellent https://github.com/nektos/act
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.
Count yourself lucky you've never had to deal with any of that!
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.
You can't run a GitHub CI pipeline locally (in general; there are some projects to try but they're limited). Even if you make as much of it runnable locally as possible (which you should) you're inevitably going to end up debugging some stuff by making commits and pushing them. Release automation. Test reporting. Artifact upload. Pipeline triggers. Permissions. Count yourself lucky you've never had to deal with any o…
> Release automation. Test reporting. Artifact upload.
Those I can actually all do locally for my open source projects on GitHub, if I the correct credentials in my env. It is all automated(which I developed/tested locally) but I can break glass if needed.
Earlier quoted context omitted.
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.
I 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 environm…
> Then it loops while there's an active SSH session present.
From what I can see, the loop stops when a user is logged in. Is this handled elsewhere?
> use Taskfiles inside a Docker container since then, so my local environment can replicate the CI/CD environment
Oh this is what I've been wanting, a vendor-neutral way to run the same CI actions locally. I'd seen go-task before, will try it, thanks for the info!
Earlier quoted context omitted.
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.
I 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 environm…
That looks like a useful trick, using an ephemeral instance to SSH into a failed CI action context. I see in the script how it waits and checks for root user login, but to keep it alive, this part: > Then it loops while there's an active SSH session present. From what I can see, the loop stops when a user is logged in. Is this handled elsewhere? > use Taskfiles inside a Docker container since then, so my local enviro…
Yup. And Tailscale even manages the SSH key provisioning.
> From what I can see, the loop stops when a user is logged in. Is this handled elsewhere?
The script does handle it. The `pgrep` succeeds (returns zero exit code) if there's a "login" process for user 'root' present, which is created when there's an active SSH session. If pgrep fails, then `break` runs and exits the loop.
Github then terminates the workflow and releases the runner.
Earlier quoted context omitted.
That looks like a useful trick, using an ephemeral instance to SSH into a failed CI action context. I see in the script how it waits and checks for root user login, but to keep it alive, this part: > Then it loops while there's an active SSH session present. From what I can see, the loop stops when a user is logged in. Is this handled elsewhere? > use Taskfiles inside a Docker container since then, so my local enviro…
> That looks like a useful trick, using an ephemeral instance to SSH into a failed CI action context. Yup. And Tailscale even manages the SSH key provisioning. > From what I can see, the loop stops when a user is logged in. Is this handled elsewhere? The script does handle it. The `pgrep` succeeds (returns zero exit code) if there's a "login" process for user 'root' present, which is created when there's an active SS…