10 ms·

I hate GitHub Actions with passion

• spockz 9mo ago
  Would a tool like act help here? (https://github.com/nektos/act https://github.com/nektos/act) I suppose orchestration that is hiding things from different processor architectures could also very well run differently online than offline, but still.
  • c0wb0yc0d3r 9mo ago
    I haven’t looked into act for some time but I remember it NOT being a direct stand in locally. Like it covered 80% of use cases. Maybe that has changed.
    • wannabe_loser 9mo ago
      it still isn't an 100% drop-in replacement
    • joshstrange 9mo ago
      That's correct and it's linux-only (as of the last time I looked), you can run it on macOS but you can't run macOS runners (which is where I need the most help debugging normally, for building iOS apps).
  • palata 9mo ago
    I think really what would help is a way to SSH into the machine after it fails. SourceHut allows that, and I find it great.
  • Mattwmaster58 9mo ago
    It's generally very helpful - someone else mentioned here the fundamental problem is lack of a tight feedback loop. It doesn't perfectly replicate the GH environment, but for my use case that doesn't matter and it's super nice to have.
• Hamuko 9mo ago
  >Now of course, in some Perfect World, GitHub could have a local runner with all the bells and whistles. Not by GitHub, but isn't act supposed to be that? https://github.com/nektos/act https://github.com/nektos/act
  • figmert 9mo ago
    Prefacing this with the fact that act is great, however, it has many shortcomings. Too often I've run into roadblocks, and when looking up the issue for it, it seems they are hard to address. Simpler workflows work fine with it, but more complex workflows will be much harder. Don't put your logic in proprietary tooling. I have started writing all logic into mise tasks since I already manage the tool dependencies with mise. I tend to write them in a way where it can easily take advantage of GHA features such as concurrency, matrixes, etc. But beyond that, it is all running within mise tasks.
  • xlii 9mo ago
    act is often mentioned as a drop-in replacement but I never got it to replicate GitHub actions environment. I didn't try it for this particular case, though.
• iamcalledrob 9mo ago
  > For the love of all that is holy, don’t let GitHub Actions > manage your logic. Keep your scripts under your own damn > control and just make the Actions call them! The pain is real. I think everyone that's ever used GitHub actions has come to this conclusion. An ideal action has 2 steps: (1) check out the code, (2) invoke a sane script that you can test locally. Honestly, I wonder if a better workflow definition would just have a single input: a single command to run. Remove the temptation to actually put logic in the actions workflow.
  • worldsayshi 9mo ago
    > I think everyone that's ever used GitHub actions has come to this conclusion. I agree that that should be reasonable but unfortunately I can tell you that not all developers (including seniors) naturally arrive at such conclusion no.
  • ImHereToVote 9mo ago
    I thought that's how actions are supposed to work. Python is king. Just use the Actions script to feed your variables.
  • Conan_Kudo 9mo ago
    This is basically how most other CI systems work. GitLab CI, Jenkins, Buildbot, Cirrus CI, etc. are all other systems I've used and they work this way. I find GitHub Actions abhorrent in a way that I never found a CI/CD system before...
    • embedding-shape 9mo ago
      > I find GitHub Actions abhorrent in a way that I never found a CI/CD system before... That's just the good old Microsoft effect, they have a reverse-midas-touch when it comes to actually delivering good UX experiences.
    • blibble 9mo ago
      as usual for Microslop products: it's designed for maximum lock-in everything is including some crappy proprietary yaml rather than using standard tooling so instead of being a collection of easily composable and testable bits it's a mess that only works on their platform
• frankwiles 9mo ago
  I actually built the last thing last weekend weirdly enough. gg watch action Finds the most recent or currently running action for the branch you have checked out. Among other things. https://github.com/frankwiles/gg https://github.com/frankwiles/gg
  • drcongo 9mo ago
    Oh this is excellent. This is everything I wanted the `gh` cli to be, thanks. edit: Just a quick note, the `gg` and `gg tui` commands for me don't show any repos at all, the current context stuff all works perfectly though.
    • frankwiles 9mo ago
      Ah sorry need to make the docs more clear. You need to run ‘gg data refresh’ to populate the local DB first.
      • drcongo 9mo ago
        Ah, magnificent! Thanks!
        • frankwiles 9mo ago
          Sure thing. Also just made it easier to install with Homebrew since people seem to be liking it.
          • drcongo 9mo ago
            May also be worth adding mise to the README install options given its growing popularity. I installed globally with `mise use -g ubi:frankwiles/gg@latest`. I've invoked gg so many times over the last day, it's exactly what I needed - thanks again.
• n0us 9mo ago
  [flagged]
  • bryanrasmussen 9mo ago
    is it your contention that once anybody becomes sufficiently skillful with a technology they will come to love it? And thus stating that one does not love the specific technology demonstrates the lack of skill?
• ZiiS 9mo ago
  Of all the valid complaints about Github Actions or CI in general, this seems to be an odd one. No details about what was tried or not tried, but hard to see a `-run: go install cuelang.org/go/cmd/cue@latest` step not working?
• g947o 9mo ago
  So the article is about the frustrating experience of fixing GitHub Actions when something goes wrong, especially when a workflow only fails on one platform, potentially due to how GitHub runner is set up (inconsistently across platforms). Took me a while to figure that out. While I appreciate occasional banters in blog articles, this one seems to diverge into rant a bit too much, and could have made its point much clearer, with, for example, meaningful section headers.
• arch1t3cht 9mo ago
  A lot of the pain of GitHub Actions gets much better using tools like action-tmate: https://github.com/mxschmitt/action-tmate https://github.com/mxschmitt/action-tmate As soon as I need more than two tries to get some workflow working, I set up a tmate session and debug things using a proper remote shell. It doesn't solve all the pain points, but it makes things a lot better.
  • figmert 9mo ago
    Tmate is not available anymore, and will be fully decommissioned[0]. Use upterm[1] and action-upterm[2] instead. Honestly, this should be built into GitHub Actions. [0] https://github.com/tmate-io/tmate/issues/322 https://github.com/tmate-io/tmate/issues/322 [1] https://upterm.dev/ https://upterm.dev/ [2] https://github.com/marketplace/actions/debug-with-ssh https://github.com/marketplace/actions/debug-with-ssh
• 1a527dd5 9mo ago
  1. Don't use bash, use a scripting language that is more CI friendly. I strongly prefer pwsh. 2. Don't have logic in your workflows. Workflows should be dumb and simple (KISS) and they should call your scripts. 3. Having standalone scripts will allow you to develop/modify and test locally without having to get caught in a loop of hell. 4. Design your entire CI pipeline for easier debugging, put that print state in, echo out the version of whatever. You don't need it _now_, but your future self will thank you when you do it need it. 5. Consider using third party runners that have better debugging capabilities
  • Storment33 9mo ago
    I would disagree with 1. if you need anything more than shell that starts to become a smell to me. The build/testing process etc should be simple enough to not need anything more.
    • embedding-shape 9mo ago
      That's literally point #2, but I had the same reaction as you when I first read point #1 :)
      • Storment33 9mo ago
        I agree with #2, I meant more if you are calling out to something that is not a task runner(Make, Taskfile, Just etc) or a shell script thats a bit of a smell to me. E.g. I have seen people call out to Python scripts etc and it concerns me.
        • embedding-shape 9mo ago
          Huh? Who cares if the script is .sh, .bash, Makefile, Justfile, .py, .js or even .php? If it works it works, as long as you can run it locally, it'll be good enough, and sometimes it's an even better idea to keep it in the same language the rest of the project is. It all depends and what language a script is made in shouldn't be considered a "smell".
• g947o 9mo ago
  Is any of this unique to GitHub Actions that does not happen on other cloud CI platforms?
  • embedding-shape 9mo ago
    The best CI platforms let you "Rebuild with SSH" or something similar, and instead of having the cycle of "change > commit > push > wait > see results" (when you're testing CI specific stuff, not iterating on Makefiles or whatever, assuming most of it is scripts you can run both locally and in CI), you get a URL to connect to while the job is running, so you can effectively ensure manually it works, then just copy-paste whatever you did to your local sources.
    • cesarvarela 9mo ago
      There are a couple of GitHub actions that let you do this.
      • alfonsodev 9mo ago
        do you mean https://github.com/nektos/act https://github.com/nektos/act or there is something else ?
        • efrecon 9mo ago
          No. Act is for running actions locally. What was mentioned is a way to insert an SSH step at some well-chosen point of a workflow so you can login at the runner and understand what is wrong and why it's not working. I have written one such thing, it relies on cloudflare free tunnels. https://github.com/efrecon/sshd-cloudflared https://github.com/efrecon/sshd-cloudflared. There are other solutions around to achieve more or less the same goal.
    • palata 9mo ago
      I use that a lot with SourceHut: after a build fails, you have 10 minutes to SSH into the machine and debug from there. Also they have a very nice "edit manifest and run" feature that makes it easy to quickly test a change while debugging. Are there other platforms allowing that? Genuinely interested.
• Storment33 9mo ago
  > For the love of all that is holy, don’t let GitHub Actions > manage your logic. Keep your scripts under your own damn > control and just make the Actions call them! I mean your problem was not `build.rs` here and Makefiles did not solve it, was your logic not already in `build.rs` which was called by Cargo via GitHub Actions? The problem was the environment setup? You couldn't get CUE on Linux ARM and I am assuming when you moved to Makefiles you removed the need for CUE or something? So really the solution was something like Nix or Mise to install the tooling, so you have the same tooling/version locally & on CI?
  • Storment33 9mo ago
    [dead]
  • turboponyy 9mo ago
    Exactly. "GitHub actions bad" is a valid take - you should reduce your use to a minimum. "My build failed because of GitHub actions couldn't install a dependency of my build" is a skill issue. Don't use GitHub actions to install a program your build depends on.
• ekjhgkejhgk 9mo ago
  > Even though my user base can be counted on a fingers of one-arm-less and second-arm-hook-equipped pirate, it’s still a thing “One Should Do”. No. It's cargo cult science.
  • nish__ 9mo ago
    I agree. Why are you building for platforms you don't even use?
  • pjc50 9mo ago
    I wouldn't say that, but I would say there's no "should" here; it's often much more hassle than people expect and everyone has to decide for themselves whether the number of users is worth it.
• mrweasel 9mo ago
  The love for Github Actions dissipated fast, it wasn't that long ago we had to read about how amazing Github Actions where. What changed?
  • esafak 9mo ago
    We used it.
    • munk-a 9mo ago
      And we realized that the bs sales/marketing material was just as bs as always.
  • this_user 9mo ago
    The typical cycle of all technologies: 1) New technology comes out, people get excited 2) People start recognising the drawbacks of the technology 3) Someone else makes an improved version that claims to fix all of the issues. GOTO 1
  • woodruffw 9mo ago
    I think it's possible to both think GitHub Actions is an incredible piece of technology (and an incredible de facto public resource), while also thinking it has significant architectural and experiential flaws. The latter can be fixed; the former is difficult for competitors to replicate. (In general, I think a lot of criticisms of GitHub Actions don't consider the fully loaded cost of an alternative -- there are lots of great alternative CI/CD services out there, but very few of them will give you the OS/architecture matrix and resource caps that GitHub Actions gives every single OSS project for free.)
  • palata 9mo ago
    I think it made CI management more accessible. Before that, most people would avoid Jenkins and probably never try Buildbot (because devs typically don't want to spend any time learning tools). Devs would require "devops" to do the CI stuff. Again, mostly because they couldn't be arsed to make it themselves, but also because it required setting up a machine (do you self-host, do you use a VPS?). Then came tools like Travis or CircleCI, which made it more accessible. "Just write some kind of script and we run it on our machines". Many devs started using that. And then came GitHub Actions, which were a lot better than Travis and CircleCI: faster, more machines, and free (for open source projects at least). I was happy to move everything there. But as soon as something becomes more accessible, you get people who had never done it before. They can't say "it enables me to do it, so it's better than me relying on a devops team before" or "well it's better than my experience with Travis". They will just complain because it's not perfect. And for the OP's defense, I do agree that not being able to SSH into a machine after the build fails is very frustrating.
• thewhitetulip 9mo ago
  Until I resd this blog I was under the impression that everyone wrote Python/ other files and used Github Actions to just call the scripts! This way we can test it on local machine before deployment. Also as other commenters have said - bash is not a good option - Use Python or some other language and write reusabe scripts. If not for this then for the off chance that it'll be migrated to some other cicd platform
• Nextgrid 9mo ago
  The way I deal with all these terrible CI platforms (there is no good one, merely lesser evils) is to do my entire CI process in a container and the CI tool just pulls and runs that. You can trivially run this locally when needed. Of course, the platforms would rather have you not do that since it nullifies their vendor lock-in.
  • calgoo 9mo ago
    Thats what i always did for our gitlab CI pipeline, just deploy dedicated images for different purposes. We had general terraform images for terraform code, this made it easy to standardize versions etc. Then we made specific ones for projects with a lot of dependencies so we could run the deployment pipeline in seconds instead of minutes. But now you need to maintain the docker images too. All about trade-offs.
  • trollbridge 9mo ago
    The one issue with that is there isn’t a good way to containerise macOS builds.
    • philipwhiuk 9mo ago
      I mean this has been an issue building for iOS forever. The MacOS lock-in sucks really really badly.
      • pragma_x 9mo ago
        It's kind of their whole thing, when you think about it. They didn't get to where they are by playing nice with others. If you're supporting anything in the Apple ecosystem, the fix is in.
  • palata 9mo ago
    I really like the SourceHut CI, because: 1. When the build fails, you can SSH into the machine and debug it from there. 2. You can super easily edit & run the manifest without having to push to a branch at all. That makes it super easy to even try a minimum reproducible example on the remote machine. Other than that, self-hosting (with Github or preferrably Forgejo) makes it easy to debug on the machine, but then you have to self-host.
• skywhopper 9mo ago
  GHA’s componentized architecture is appealing, but it’s astonishing to me that there’s still seemingly no way to actually debug workflows, run them locally, or rapidly iterate on them in any way. Alas.
• QuiCasseRien 9mo ago
  Guys, GitHub action is a totally broken piece of s !! I know about that broken loops cause I had to deal with it an incredible number of times. I very often mention OneDev in my comments, and you know what ? Robin solved this issue 3 years ago : https://docs.onedev.io/tutorials/cicd/diagnose-with-web-terminal https://docs.onedev.io/tutorials/cicd/diagnose-with-web-term... You can pause your action, connect through a web terminal, and debug/fix things live until it works. Then, you just patch your action easily. And that’s just one of the many features that make OneDev superior to pretty much every other CI/CD product out there.
• thewillowcat 9mo ago
  I was so lonely in this opinion for so long, and it is great to see it becoming mainstream. GHA is terrible.
• weli 9mo ago
  Agreed
• semiquaver 9mo ago
  Skill issue.
  • xlii 9mo ago
    Totally agree.
  • YuukiRey 9mo ago
    Care to elaborate?
  • palata 9mo ago
    To some extent I do agree that is sounds like "my build was failing on a platform I had never tested, and I was pissed because I had to debug it". But it is true that GitHub Actions don't make it easy to debug (e.g. you can't just SSH into the machine after the build fails). Not sure if it justifies hating with Passion, though.
• trollbridge 9mo ago
  I avoid actions for these exact reasons unless I can run the exact same build on another host. And that’s where there’s a Mac Studio that sits sadly in the corner, waiting for a new check in so it has something to do.
• dev_l1x_be 9mo ago
  Who doesn’t? I use it with Mise to have a very simple locally tested way or running tasks.
• jerf 9mo ago
  I think this is a specific example of a generalized mistake, one that various bits of our infrastructure and architecture all but beg us to make, over and over, and which must be resisted, which is: Your development feedback loop must be as tight as possible. Granted, if you are working on "Windows 12", you won't be building, installing, testing, and deploying that locally. I understand and acknowledge that "as tight as possible" will still sometimes push you into remote services or heavyweight processes that can't be pushed towards you locally. This is an ideal to strive for, but not one that can always be accomplished. However, I see people surrender the ability to work locally much sooner than they should, and implement massively heavyweight processes without any thought for whether you could have gotten 90% of the result of that process with a bit more thought and kept it local and fast. And even once you pass the event horizon where the system as a whole can't be feasibly built/tested/whatever on anything but a CI system, I see them surrendering the ability to at least run the part of the thing you're working on locally. I know it's a bit more work, building sufficient mocks and stubs for expensive remote services that you can feasibly run things locally, but the payoff for putting a bit of work into having it run locally for testing and development purposes is just huge, really huge, the sort of huge you should not be ignoring. "Locally" here does not mean "on your local machine" per se, though that is a pretty good case, but more like, in an environment that you have sole access to, where you're not constantly fighting with latency, and where you have full control. Where if you're debugging even a complex orchestration between internal microservices, you have enough power to crank them all up to "don't ever timeout" and attach debuggers to all of them simultaneously, if you want to. Where you can afford to log every message in the system, interrupt any process, run any test, and change any component in the system in any manner necessary for debugging or development without having to coordinate with anyone. The more only the CI system can do by basically mailing it a PR, and the harder it is to convince it to do just the thing you need right now rather than the other 45 minutes of testing it's going to run before running the 10 second test you actually need, the worse your development speed is going to be. Fortunately, and I don't even how exactly the ratio between sarcasm and seriousness here (but I'm definitely non-zero serious), this is probably going to fix itself in the next decade or so... because while paying humans to sit there and wait for CI and get sidetracked and distracted is just Humans Doing Work and after all what else are we paying them for, all of this stuff is going to be murder on AI-centric workflows, which need tight testing cycles to work at their best. Can't afford to have AI waiting for 30 minutes to find out that its PR is syntactically invalid, and can't afford for the invalid syntax to come back with bad error messages that leave it baffled as to what the actual problem is. If we won't do it for the humans, we'll do it for the AIs. This is definitely not something AI fixes, despite the fact they are way more patient than us and much less prone to distraction in the meantime since from their "lived experience" they don't experience the time taken for things to build and test, it is made much worse and more obvious that this is a real problem and not just humans being whiny and refusing to tough it through.
• jbmilgrom 9mo ago
  just came here to say same, they are the absolute worst
• woodruffw 9mo ago
  I think this post accurately isolates the single main issue with GitHub Actions, i.e. the lack of a tight feedback loop. Pushing and waiting for completion on what's often a very simple failure mode is frustrating. Others have pointed out that there are architectural steps you can take to minimize this pain, like keeping all CI operations isolated within scripts that can be run locally (and treating GitHub Actions features purely as progressive enhancements, e.g. only using `GITHUB_STEP_SUMMARY` if actually present). Another thing that works pretty well to address the feedback loop pain is `workflow_dispatch` + `gh workflow run`: you still need to go through a push cycle, but `gh workflow run` lets you stay in development flow until you actually need to go look at the logs. (One frustrating limitation with that is that `gh workflow run` doesn't actually spit out the URL of the workflow run it triggers. GitHub claims this is because it's an async dispatch, but I don't see how there can possibly be no context for GitHub to provide here, given that they clearly obtain it later in the web UI.)
  • echelon 9mo ago
    We need SSH access to the failed instances so we can poke around and iterate from any step in the workflow. Production runs should be immutable, but we should be able to get in to diagnose, edit, and retry. It'd lead to faster diagnosis, resolution, and fixing. The logs and everything should be there for us. And speaking of the logs situation, the GHA logs are really buggy sometimes. They don't load about half of the time I need them to.
    • dweekly 9mo ago
      Are there solutions to this like https://github.com/marketplace/actions/ssh-to-github-action-runner https://github.com/marketplace/actions/ssh-to-github-action-... ?
    • lawrencegripper 9mo ago
      I wrote something recently with webrtc to get terminal on failure: https://blog.gripdev.xyz/2026/01/10/actions-terminal-on-failure-for-debugging/ https://blog.gripdev.xyz/2026/01/10/actions-terminal-on-fail...
  • 9mo ago
• smetj 9mo ago
  Its not Github Actions' fault but the horrors people create in it, all under the pretense that automation is simply about wrapping a GitHub Action around something. Learn to create a script in Python or similar and put all logic there so you can execute it locally and can port it to the next CI system when a new CTO arrives.
  • bandrami 9mo ago
    This is giving "Debian systemd units call their old init.d scripts" energy but I kind of like it
    • lionkor 9mo ago
      systemd units that are small, simple, and call into a single script are usually fantastic. There's no reason for these scripts to be part of another init system; but making as much of your code completely agnostic to the env it runs in sounds good regardless. I think that's the feeling you're feeling.
  • palata 9mo ago
    I think in this case they hate the fact that they cannot easily SSH into the failing VM and debug from there. Like "I have to edit my workflow, push it, wait for it to run and fail, and repeat".
    • rurp 9mo ago
      Yep, my company moved onto GH Actions a few years ago and this was probably the single biggest pain point. But also the whole system just feels awkward and annoying to work with. It feels like a classic Microsoft product that would never get traction from a standalone company but because it's part of Microsoft/GitHub and is "good enough" lots of people put up with it.
    • anttiharju 9mo ago
      One can get the ssh access with self-hosted runners but it is problematic because uncovering secrets becomes trivial.
• bob1029 9mo ago
  For the last decade I've been doing my CI/CD as simple .NET console apps that run wherever. I don't see why we switch to these wildly different technologies when the tools we are already using can do the job. Being able to run your entire "pipeline" locally with breakpoints is much more productive than whatever the hell goes on in GH Actions these days.
  • juliie 9mo ago
    I can do that with github actions too? For tests, I can either run them locally (with a debugger if I want), or in github actions. Smaller checks go in a pre-commit config that github action also runs. Setting up my github actions (or gitlab) checks in a way that can easily run locally can be a bit of extra work, but it's not difficult.
• blixt 9mo ago
  I've gotten to a point where my workflow YAML files are mostly `mise` tool calls (because it handles versioning of all tooling and has cache support) and webhooks, and still it is a pain. Also their concurrency and matrix strategies are just not working well, and sometimes you end up having to use a REST API endpoint to force cancel a job because their normal cancel functionality simply does not take. There was a time I wanted our GH actions to be more capable, but now I just want them to do as little as possible. I've got a Cloudflare worker receiving the GitHub webhooks firehose, storing metadata about each push and each run so I don't have to pass variables between workflows (which somehow is a horrible experience), and any long-running task that should run in parallel (like evaluations) happens on a Hetzner machine instead. I'm very open to hear of nice alternatives that integrate well with GitHub, but are more fun to configure.
• arximboldi 9mo ago
  I like Github Actions and it is better than what I used before (Travis) and I think it solves an important problem. For OSS projects it's a super valuable free resource. For me what worked wonders was adopting Nix. Make sure you have a reproducible dev environment and wrap your commands in `nix-shell --run`, or even better `nix develop --command`, or even better your most of your CI tasks derivations that run with `nix build` or `nix flake check`. Not only does this make it super easy to work with Github Actions, also with your colleagues or other contributors.
  • anttiharju 9mo ago
    Second the Nix approach. One can even build a github actions-compatible container out of a flake and have actions run in it. I have done so for my personal projects https://github.com/anttiharju/compare-changes https://github.com/anttiharju/compare-changes
    • dfee 9mo ago
      isn't this better served with something like Bazel (behind Nix of course?)
      • anttiharju 9mo ago
        Could be, not familiar with Bazel. Thanks for mentioning it now can check it out.
• BirAdam 9mo ago
  In general, I've never really experienced the issues mentioned, but I also use Gitea with Actions rather than GitHub. I also avoid using any complex logic within an Action. For the script getting run, there's one other thing. I build my containers locally, test the scripts thoroughly, and those scripts and container are what are then used in the build and deploy via Action. As the entire environment is the same, I haven't encountered many issues at all.
  • lionkor 9mo ago
    That sounds sane and also completely different from GH Actions.
• gen220 9mo ago
  If you wanted a better version of GitHub Actions/CI (the orchestrator, the job definition interface, or the programming of scripts to execute inside those jobs), it would presumably need to be more opinionated and have more constraints? Who here has been thinking about this problem? Have you come up with any interesting ideas? What's the state of the art in this space? GHA was designed in ~2018. What would it look like if you designed it today, with all we know now?
  • shykes 9mo ago
    I've been working for the last 5 years on an alternative called Dagger. Ended up building a company around it. We started from the ideal state of CI, and set out to build the platform that would support that. For us this ideal state of CI boils down to 4 things: - local-first (local execution should be a first-class citizen, with no exception) - repeatable (the same inputs should yield the same output, with affordances for handling inevitable side effects in an explicit and pragmatic way) - programmable. my workflows are software. I want all the convenience of a modern software development experience: types, IDE support, a rich system API , debugging tools, an ecosystem of reusable components, etc. - observable. I want all the information in one place about everything that happened in my workflow, with good tooling to get the information I need quickly, and interop with the existing observability ecosystem (eg. open telemetry) So Dagger is our best effort at a CI platform focused on those 4 things. Sorry if this comes across as a sales pitch. When you're building solves a problem you're obsessed with, it's hard to discuss the problem without also mentioning the solution that seems the most obvious to you :)
    • jgautsch 9mo ago
      I've been watching Dagger with great interest, although have not moved production workloads to it (nor, admittedly, even committed an afternoon to setting up any workflows/graphs). Passive comment readers should be aware that ^shykes here cofounded Docker (my gratitude), so it's really worth a look. Can anyone comment on the ergonomics of Dagger after using it for a while? I was just looking at the docs earlier this week to consider a migration but got confused by the AI sections...
• wrqvrwvq 9mo ago
  Standard msft absurdity. 8 years later there is still no local gh action runner to test your script before you commit, push, and churn through logs, and without some 3rd party hack, no way to ssh in and debug. It doesn't matter how simple the build command you write is, because the workflow itself is totally foreign technology to most, and no one wants to be a gh action dev. Like most of the glaring nonsense that costs people time when using msft, this is financially beneficial to msft in that each failed run counts against paid minutes. It's a racket from disgusting sleaze scum who literally hold meetings dedicated to increasing user pain because otherwise the bottom line will slip fractionally and no one in redmond has a single clue how to make money without ripping off the userbase.
• thrown_in_dust 9mo ago
  Skill issue bro: https://github.com/nektos/act https://github.com/nektos/act
• thrown_in_dust 9mo ago
  skill issue bro https://github.com/nektos/act https://github.com/nektos/act
• swyx 9mo ago
  fyi i maintain a repo that accidentally tracks github actions cron reliability (https://www.swyx.io/github-scraping https://www.swyx.io/github-scraping) - just runs a small script every hour. i just checked and in 2025 there was at least 2 outages a month every month https://x.com/swyx/status/2011463717683118449?s=20 https://x.com/swyx/status/2011463717683118449?s=20 . not quite 3 nines.
• dundarious 9mo ago
  Of course avoid Actions if you expect tasks to complete promptly or ever. Have we forgotten safe_sleep.sh? I don't think it was unique.
• grugdev42 9mo ago
  I know GitHub Actions won the war, but I think Bitbucket Pipelines are much nicer to work with. They just seem simpler and less fragile. But almost every company uses GitHub, and changing to Bitbucket isn't usually viable.
  • normie3000 9mo ago
    The main downside of bitbucket pipelines is bitbucket. And the only significant feature I recall over GitHub Actions is that Pipelines support cron jobs.
    • normie3000 9mo ago
      Reading the rest of the thread, it looks like Actions also has cron jobs.
      • b40d-48b2-979e 9mo ago
        Correct. on: schedule: - cron: $expression
• anttiharju 9mo ago
  Issue is, op is trying to use matrix strategy when with cross-compiling they could avoid it. I have done it for https://github.com/anttiharju/compare-changes https://github.com/anttiharju/compare-changes (which has nontrivial CI pipelines but they could be a lot simpler for op's needs) Main issue is Rust. Writing catchy headlines about hating something may feel good, but a lot of people could avoid these pains if - zig cc gets support for new linker flag that Rust requires https://codeberg.org/ziglang/zig/pulls/30628 https://codeberg.org/ziglang/zig/pulls/30628 - rust-lang/libc gets to 1.0 which removes iconv issues for macos https://github.com/rust-lang/libc/issues/3248 https://github.com/rust-lang/libc/issues/3248
  • anttiharju 9mo ago
    This also helps one to avoid the expensive macos runners
  • AmazingTurtle 9mo ago
    Ah a classic stack overflow flavored answer ala: do it differently so you don't encounter these issues
    • anttiharju 9mo ago
      Does this discredit the answer?
• Imustaskforhelp 9mo ago
  Wrote a comment to someone here but I thought of deciding to make a main comment here as well Note that I don't really use github actions much but have heard about its architecture From my understanding, I feel like Github actions should just be a call to some bash or python file. Bash has its issues so I prefer python I recommend people to take a look at https://paulw.tokyo/standalone-python-script-with-uv/ https://paulw.tokyo/standalone-python-script-with-uv/ and please tell me if something like this might be perfect for python scripts in github actions as this script would automatically install uv, get all the dependencies of python and even the runtime I think and then execute the python code all while being very managable usually and it can run locally as well The only Issue I feel like I might have with this is say why go something with this complex when bash exists or the performance concerns of installing uv but considering its github actions, I feel like the latter is ruled out. Bash is good as well but bash has some severe limitations. and I feel like Python can be good case for something like this plus its ecosystem is a bit mature and you could even create web servers or have some logs be reported to your custom server or automate just basically everything To me this script feels like the best of both worlds and something genuinely sane to build upon.
  • flohofwoe 9mo ago
    > I feel like Github actions should just be a call to some bash or python file. Bash has its issues so I prefer python ...and that's how it is supposed to be used. The YAML file is mainly there for defining the runtime environment (e.g. the operating system or docker image to run in), and to describe the job dependency tree. The actual actions to execute should be delegated to scripts outside the GH YAML.
• flohofwoe 9mo ago
  GH Actions isn't great compared to other CI systems, but it's also not particularly worse until you get into the nitty gritty details. The most important advice is probably to put as much code as possible into locally runnable scripts written in a cross-platform scripting language (e.g. Python or Node.js) to avoid 'commit-push-ci-failure' roundtrips. Only use the GH Actions YAML for defining the runtime environment and job dependency tree.
  • tracker1 9mo ago
    s/Node/Deno/ - direct repo/module references, no install step required.
• isaacvando 9mo ago
  You should try RWX! You can trigger runs from the CLI for way faster feedback loops. The automatic caching is surprisingly good too. https://www.rwx.com/ https://www.rwx.com/
  • kylekthompson 9mo ago
    Thanks for the shoutout! If anyone has any questions or wants to give it a shot, I work at RWX and would be happy to chat more about it!
• jillesvangurp 9mo ago
  I think the root problem here is scope creep on using build tools, configuration management, and ci tools: don't make them do things they are not designed for / weak at. The issue isn't necessarily github ci, which is fine if you keep it simple. But things just getting to the stage where they are not simple anymore. I've seen this over and over again over the years in projects where things like ant, maven, gradle, puppet, ansible, etc. Invariably somebody tries to do something really complicated/clever in a convoluted way. They'll add plugins, more plugins, all sorts of complex configuration, etc. Your script complexity explodes. And then it doesn't work and you spend hours/days trying to make it do the right thing and fighting a tool that just wasn't designed to do what you are doing well. The problem is using the wrong tool for the job. All these tools have the tendency to evolve into everything tools. And they just aren't good at everything. Just because it has some feature doesn't mean it's a good idea to use it. The author actually calls this out. Just write a bash script and run that instead. If that gets too complicated pick something else more appropriate to the job. Python, whatever you like. The point here is to pick something that's easy for you to run, test, and debug locally. Obviously people have different preferences here. If you are shoe horning complex fork/join behavior, conditional logic, etc. into a Yaml / CI build, maybe simplify your build. Yaml just isn't suitable as a general purpose programming language. Externalizing the complex stuff to some script also has the benefit of that stuff still working if you ever decide to switch CI provider. Maybe you want to move to Gitlab. Or somebody decides Jenkins wasn't so bad after all. The same scripts will probably be easy to adapt to those. One of my current github actions basically starts a vm, runs a build.sh script, stops the vm. I don't need a custom runner for that. I get to pick the vm type. I can do whatever I need to in my build.sh. I have one project with an actual matrix build. But that's about the most complex thing I do with github actions. A lot of my build steps are just inline shell commands. And obligatory AI comment here, if you are doing all this manually, having scripts that run locally also means you can put claude code/codex/whatever to work fixing them for you. I've been working on some ansible scripts with codex today. Works great. It produces better ansible scripts than me. These tools work better if they can test/run what they are working on.
• JohnMakin 9mo ago
  I've always found things like AWS codebuild or even just a self hosted bare bones jenkins server far easier to work with. What is the advantage that github actions provide that people put up with it? The feedback seems almost universally negative.
  • anttiharju 9mo ago
    > What is the advantage that github actions provide that people put up with it? It's the default CI system on github and you get relatively free compute.
  • bdcravens 9mo ago
    Being free or practically free for many use cases. Especially if you consider multi-CPU builds.
  • moduspol 9mo ago
    It is overwhelmingly less resource-intensive to maintain over time than any Jenkins server. And the config is in the repo (not the Jenkins server's config).
• mrgoldenbrown 9mo ago
  This is very validating as someone just trying out Actions and getting frustrated with the less than ideal UX.
• eYrKEC2 9mo ago
  Anyone use Argo Workflows as an alternative?
• kylegalbraith 9mo ago
  As a founder of Depot [0], where we offer our own faster and cheaper GitHub Actions runners, I can assure everyone that this feeling is the majority and not the minority. Sounds strange to say as someone who has a product that is built around making GitHub Actions exponentially faster to close these feedback loops faster. But I can honestly say it's only really possible because the overall system with GitHub Actions is so poor. We discover new bottlenecks in the runner and control plane weekly. Things that you'd think would be simple are either non-existent, don't work, or have terrible performance. I'm convinced there are better ways of doing things, and we are actively building ideas in that realm. So if anybody wants to learn more or just have a therapy session about what could be better with GitHub Actions, my email is in my bio. [0] https://depot.dev/ https://depot.dev/
• OptionOfT 9mo ago
  As much as I hate GitHub Actions, I prefer it over Jenkins and others, because it is right there. I don't need to go and maintain my own servers, or even talk to a 3rd party to host the services.
  • tracker1 9mo ago
    Like many things, the tool people reach for is the one that's in the box... As opposed to a trip to the hardware store, getting distracted for a few hours, coming back home and no longer in the mood to work on your project/choore.
• psyclobe 9mo ago
  I have spent the majority of my professional career waiting for ci to complete. It is hell.
• kvnnews 9mo ago
  This happens when there’s too much logic in the build server.
• UnCommonLisp 9mo ago
  I take GitHub Actions over any of the other CI platforms.
• NooneAtAll3 9mo ago
  This feels like a rage bait.
• akhil08agrawal 9mo ago
  As a PM trying to understand what was happening, it took me a minute. Turning this into an analogy so that it might benefit other non-too-techies: Original plan: You have an oven in another building that automatically bakes your cake. But the oven needs a mixer, and every time you bake, it has to wait 2-3 minutes for someone to bring the mixer from storage. Problem: For one specific oven (Linux ARM), the mixer never arrives. So your cake fails. You keep trying different ways to get the mixer delivered. Each attempt: 2-3 minutes wait. What you finally do: Stop waiting for the mixer to be delivered. Just mix the batter at home where you already have a mixer. Send the pre-mixed batter to the other building. Now the oven just bakes it - no waiting for the mixer. Translation: Stop trying to generate files in GitHub Actions (where it takes 2-3 minutes each time). Generate them locally on your computer where you already have the tools. Upload the finished files. GitHub Actions just uses them. Sometimes "pre-mix the batter at home" beats "wait for the mixer every single time."
• dwoldrich 9mo ago
  I am not having fun with GitHub Actions right now! Why does everything have to be so hard? I like being able to run self-hosted runners, that is a very cool part of GitHub Actions/Workflow. I appreciate all the other advice about limit my yamls to: 1) checkout, 2) call a script to do the entire task. I am already half-way there, just need to knuckle-down and do the work. I was dismayed that parallel tasks aren't really a thing in the yaml, I wanted to fanout a bunch of parallel tasks and I found I couldn't do it. Now that I'm going to consolidate my build process into a single script I own, I can do the fanout myself.
  • Storment33 9mo ago
    Jobs run in parallel, so if you used Make you could have one job called 'formatting' calling 'make check-formatting', one called linting calling ''make check-linting', one called 'compiling' calling 'make compile' etc.
• humanlity 9mo ago
  > i.e. a way that I could testbed different runs without polluting history of both Git and Action runs. How about writing a separate repo and testing it separately Keywords: reusable workflow/actions
  • mlrtime 9mo ago
    I tried this but then I need to mock the scripts or other external dependencies to truly test the workflows, became too much pain.
• levysoft 9mo ago
  Interesting, but the opening line threw me off: > Sure, I still make fun of the PHP I remember from the days of PHP 4.1, but even then I didn’t hate it. (ref. And “PHP: Training Wheels Without a Bike” is still in the Top 10 of my favorite memes.) I still use it to build my latest projects, and for me it’s like breathing. Simple and functional. It’s not perfect, but no language is.
  • jslaby 9mo ago
    Yeah, no reason for PHP to catch strays here, especially if his knowledge is still based on 4.1. It's really a whole new language compared to back then.
• globular-toast 9mo ago
  What always surprises me in these discussions is how few people have used GitLab CI. What gives? It's far, far superior to GitHub and even existed first.
  • c-hendricks 9mo ago
    I found gitlab ci's yaml the smallest of the 3 I've used (gitlab, GitHub actions, CircleCI). But does gitlab ci have anything for sharing? GitHub actions are built around it, and CircleCI has orbs and contexts. For example, muse's guide for gitlab involves making your own container and managing the cache yourself (ref: https://mise.jdx.dev/continuous-integration.html#gitlab-ci https://mise.jdx.dev/continuous-integration.html#gitlab-ci) GitHub actions is a couple of lines (ref: https://mise.jdx.dev/continuous-integration.html#github-actions https://mise.jdx.dev/continuous-integration.html#github-acti...)
    • globular-toast 9mo ago
      Not sure what you mean by "smallest". With GitLab you create docker images. That means you can easily run them locally and share them. In the example you gave the GitHub actions one looks like more lines of YAML but only works because they made an "action". If they had provided a Docker image then GitLab would be just as easy (and trivial to test locally).
      • c-hendricks 9mo ago
        mise already is trivial to test locally though, and I'm not sure I agree that maintaining a CI config + Docker image is just as easy as maintaining a CI config.
        • c-hendricks 9mo ago
          Missed my edit window, but the just-docker solution also doesn't do anything for caching, that's still left up to every job, and the `mise install`. Again, I don't mine gitlab ci, but they have no solution for sharing repeated tasks.
• wutwutwat 9mo ago
  run your ci in docker containers so github actions is just a orchestrator or try something like https://docs.dagger.io/use-cases#portable-ci https://docs.dagger.io/use-cases#portable-ci
• joshka 9mo ago
  Slap your problem in an agentic loop, this becomes the following single step: 1. Here's your goal "...", fix it, jj squash and git push, run gh pr checks --watch --fail-fast pr-link
• olivia-banks 9mo ago
  At work we have a bunch of GitHub actions for integration testing, building models, publishing, reporting, and whatnot. It was horrible to maintain and look into whenever something went wrong, so I rewrote all the individual parts in Perl and hooked them together with pipes inside GHA, and it works wonders. Also, GitHub actions itself just breaks sometimes, which is super annoying. A couple of weeks ago, half of all the macOS runner images broke when using GitHub's caching system. Seems like that would have been caught on GitHub's side before that happened, but what do I know! > https://github.com/actions/runner/issues/449 https://github.com/actions/runner/issues/449 > https://github.com/orgs/community/discussions/180160 https://github.com/orgs/community/discussions/180160
• cadamsdotcom 9mo ago
  So many engineers could put the hours spent debugging GH actions to use developing expertise to run their own CI. But people either don’t believe they can, can’t convince decision makers to let them try, or just want to fix their own problem and move on. I was convinced GH actions was best practice and it was normal to waste hours on try-and-pray build debugging, until one day GH actions went down and I ran deploys from my laptop and remembered how much better life can be without it.. (Solo dev here - but opensource CI on an EC2 instance can be just as nice)
  • Marsymars 9mo ago
    > So many engineers could put the hours spent debugging GH actions to use developing expertise to run their own CI. If I run my own CI, then the compliance team has to get involved to run various endpoint security and update management tools on whatever system I'm running the CI on.
    • cadamsdotcom 9mo ago
      Then the costs of staying with GH actions need to be made known so they can be balanced against the cost of doing things differently. Of course there’s a cost involved in just getting those numbers too. It’s all trade offs.
• deepsun 9mo ago
  > A word of explanation. I’m building tmplr for 4 platforms: > Linux ARM > macOS ARM > Linux x86_64 > macOS x86_64 Oh, here we go again. Java was invented to solve that, "Write once run everywhere" :] I.e. `int` means `i32` on all platforms, no `usize`.
  • Storment33 9mo ago
    Java has numerous problems, it's not as simple as use Java not Rust. To be honest I actively avoid any tooling written in Java.
    • deepsun 9mo ago
      jAvA BaD!!1
• bitterbytes 9mo ago
  Would something like this help with the feed back loop? https://github.com/nektos/act https://github.com/nektos/act
• wasmainiac 9mo ago
  Honestly part of the reason why I left my last job was because I had to extensively work with GitHub workflows and actions. Debugging was absolutely hell, especially with long running tasks (~1hr) that would fail with next to no debug or traceability. I offered many times to overhaul the system and make it easier to maintain, but we had no time budget. I now work for 30% less but am substantially happier in life without github. It sounds crazy, but I’m not exaggerating.
• nfw2 9mo ago
  I am surprised that these sort of declarative specs are so popular in certain domains. Essentially you always seem to be putting settings into the ether and hoping they interact with each other in the way you expect. I prefer an api with documented contracts between its abstractions
• kitplummer 9mo ago
  I recently, for Rust targets reasons, have decided to punt GitHub Actions AND GitHub. Opted for Radicle. Had to figure out my own CI. Doc'd it here: https://revolveteam.com/blog/goa-radicle-ci/ https://revolveteam.com/blog/goa-radicle-ci/
• ted537 9mo ago
  The main problem with actions is the way they advertise its usage "just put workflows together" is a horrible and non-debuggable way to do things. But even in the tech itself, caching is pretty stingy which can slow dev builds for fairly simple projects because every run will repeat some common work unless you have the cache perfectly configured (did u cover npm, docker, etc. with cache keys correctly?) Looking at these flaws, running workflows from a persistent VM of ur own becomes pretty tempting because you don't need to copy caches around and can easily SSH in.
• arialdomartini 9mo ago
  First time I see jj being mentioned in a post not about jj. Made me very happy.
• notepad0x90 9mo ago
  For those who have experience, how does github actions compare to azure devops pipelines?
  • deleted 9mo ago
    [deleted]
• imetatroll 9mo ago
  Is there still no way to ssh into an instance? If not, then github actions needs to work on that.
• theteapot 9mo ago
  > I can’t overstate how much I hate GitHub Actions. I don’t even remember hating any other piece of technology I used. Ansible. Same reasons but 100x worse.
• sashank_1509 9mo ago
  lol, this post makes me feel like crying at my job in BigTech co. He’s complaining about a 30 min feedback loop maybe, mine is 2+ hours. I write a piece of code, however small the change. Then run the proc, first it takes ~20 mins to compile. Then since it is ML, it can only run on a remote server. It takes an easy 20 more minutes to start running in the remote server. Then after another 40 minutes I can confirm the job failed. The only way to debug is to read through a massive log file, for which we have an in built log reader lol. The log file will have thousands of errors that literally don’t matter, and you’ll never have enough context to know which errors don’t matter. You can simply ping someone and ask, does this error matter, could this be the reason my entire proc failed, oh no this is just a useless log that fails all the time, I shouldn’t have been wasting a day digging into this, ok thanks bye. But this isn’t it, not even close lol, we in fact have a custom DSL to define computational graphs, which of course does not have any linter, or even any compiler and a very broken visualizer but our entire org runs on this. Syntax errors, logic errors, actual race conditions are all caught the exact same way —- as the process dying after trying to run on a remote server for 2+ hours with no useful error log. So our workflow is to just get a cup of coffee and stare at the graph which can get thousands and thousands of lines big to find at times completely trivial bugs that any half decent language would have caught as a syntax error. My exp in BigTechCo makes me completely understand GitHub actions, my guess is many big companies have equally janky tools that harm dev productivity but still somehow take absolutely massive workloads. GitHub just thought of sharing it to the public.
• TZubiri 9mo ago
  Can't you just have a good ole git repo in a server, use hooks to sync with github, and more hooks when you need 'actions' TM (C) (R)
• danecjensen 9mo ago
  There's no excuse to complain about bad software these days. Fork Gitea, and make your own GitHub actions, it should take a day with coding agents.
• tdy_err 9mo ago
  > I don’t even remember hating any other piece of technology I used Jira, Microsoft Teams, HP Printers, Ticketmaster, …
• codingbot3000 9mo ago
  I still do not understand how anybody can set up real-life CI on Github? Have they ever looked into real CI solutions?
• melezhik 9mo ago
  “ For the love of all that is holy, don’t let GitHub Actions manage your logic. Keep your scripts under your own damn control and just make the Actions call them!” This is why I started DSCI - https://github.com/melezhik/DSCI https://github.com/melezhik/DSCI One can replace GitHub actions yaml pipeline runner by general purpose languages/scripts but still using all other standard features of GitHub server
• PufPufPuf 9mo ago
  Using jdx/mise in GitHub Actions has been very nice, I recommend it. It's not just a nice task runner, it also manages the dependencies of your tasks (stuff like Python, Node.js, even random tools from GitHub) so that "mise run build" does the exact same thing both locally and in CI. Then the ideal GHA workflow is just "install mise, run this mise task". And not only for building, we have it set up for commit checks too.
• krschacht 9mo ago
  Run your own server for GitHub Actions. There is a simple library they have you install so your runner gets registered with your repo. Then you can SSH in whenever a job fails. This lets you fully inspect the state, and to execute one-off commands to test theories. It’s a much faster way to iterate.
• dent9 9mo ago
  This authors problem isn't GitHub it's the fact that they used Rust when they should have used Go. Never would have had this issue