@dang can we get this renamed to "GitHub Actions could be better"
GitHub Actions is slowly killing engineering teams
131–140 of 219 posts
Re: GitHub Actions is slowly killing engineering teams
#132I run a company that uses Nix for everything.
We're running GitHub Actions. It's good. All the real logic is in Nix, and we mostly use our own runners. The rest of the UI that GitHub Actions provides is very nice.
We previously used a CI vendor which specialised in building Nix projects. We wanted to like it, but it was really clunky. GitHub Actions was a significant quality of life improvement for us.
None of my colleagues have died. GitHub Actions is not killing my engineering team at any rate.
Re: GitHub Actions is slowly killing engineering teams
#133After Azure DevOps and Jenkins, GitHub is like afresh breath of air. It might be a fart in your face, but at least it's available within IT department guidelines, and any movement of air is preferable to the stifling insanity of the others.
Re: GitHub Actions is slowly killing engineering teams
#134>the GitHub Actions log viewer is the only one that has crashed my browser. Not once. Repeatedly. Reliably.
Well, THIS blog post page reliably eats the CPU on scrolling, and the scrolling is very jerky, despite it has only text and no other visible elements.
Re: GitHub Actions is slowly killing engineering teams
#135All CI is just various levels of bullshit over a bash script anyway.
Yes, but no need for the attitude.
Linux powers the world in this area and bash is the glue which executes all these commands on servers.
Any program or language you write to try and 'revolutionise CI' and be this glue will ultimately make the child process call to a bash/sh terminal anyhow and you need to read both stdout and stderr and exit codes to figure out next steps.
Or you can just use bash.
Re: GitHub Actions is slowly killing engineering teams
#136The problem isn't CI/CD; the problem is "programming in configuration". We've somehow normalized a dev loop that involves `git commit -m "try fix"`, waiting 10 minutes, and repeating. Local reproduction of CI environments is still the missing link for most teams.
Bingo.
These tool fails are as a consequence of a failure of proper policy.
Tooling and Methodology!
Here’s the thing: build it first, then optimize it. Same goes for compile/release versus compile/debug/test/hack/compile/debug/test/test/code cycles.
That there is not a big enough distinction between a development build and a release build is a policy mistake, not a tooling ‘issue’.
Set things up properly and anyone pushing through git into the tooling pipeline are going to get their fingers bent soon enough, anyway, to learn how the machine mangles digits.
You can adopt this policy of environment isolation with any tool - it’s a method.
Tooling and Methodology!
Re: GitHub Actions is slowly killing engineering teams
#137The winning strategy for all CI environments is a build system facsimile that works on your machine, your CI's machine, and your test/uat/production with as few changes between them as your project requirements demand. I start with a Makefile. The Makefile drives everything. Docker (compose), CI build steps, linting, and more. Sometimes a project outgrows it; other times it does not. But it starts with one unitary to…
Make is incredibly cursed. My favorite example is it having a built-in rule (oversimplified, some extra Makefile code that is pretended to exist in every Makefile) that will extract files from a version control system.
https://www.gnu.org/software/make/manual/html_node/Catalogue...
What you're saying is essentially ”Just Write Bash Scripts”, but with an extra layer of insanity on top. I hate it when I encounter a project like this.
Re: GitHub Actions is slowly killing engineering teams
#138The winning strategy for all CI environments is a build system facsimile that works on your machine, your CI's machine, and your test/uat/production with as few changes between them as your project requirements demand. I start with a Makefile. The Makefile drives everything. Docker (compose), CI build steps, linting, and more. Sometimes a project outgrows it; other times it does not. But it starts with one unitary to…
Make is incredibly cursed. My favorite example is it having a built-in rule (oversimplified, some extra Makefile code that is pretended to exist in every Makefile) that will extract files from a version control system. https://www.gnu.org/software/make/manual/html_node/Catalogue... What you're saying is essentially ”Just Write Bash Scripts”, but with an extra layer of insanity on top. I hate it when I encounter a pro…
https://github.com/casey/just is an uncursed make (for task running purposes - it's not a general build system)
Re: GitHub Actions is slowly killing engineering teams
#139I tend to disagree with this as it seems like an ad for Nix/Buildkite... If your CI invocations are anything more than running a script or a target on a build tool (make, etc.) where the real build/test steps exist and can be run locally on a dev workstation, you're making the CI system much more complex than it needs to be. CI jobs should at most provide an environment and configuration (credentials, endpoints, etc.…
Hey, at least you didn't pull the reflexive, "this must be AI slop!" comment that seems quite prevalent on HN lately.
Re: GitHub Actions is slowly killing engineering teams
#140I think this author would benefit from using the Refined GitHub browser extension, which fixes a lot of these problems.
I think people shouldn't go installing random browser extensions like they shouldn't go installing random package manager packages, which is part of his argument