That if anything was a fun read, explains why I’ve always heard that GitHub actions were only good for personal projects
GitHub Actions is slowly killing engineering teams
101–110 of 219 posts
Re: GitHub Actions is slowly killing engineering teams
#102I've used many of the CI systems that the author has here, and I've done a lot of CircleCI and GitHub Actions, and I don't come to quite the same conclusions. One caveat though, I haven't used Buildkite, which the author seems to recommend. Over the years CI tools have gone from specialist to generalist. Jenkins was originally very good at building Java projects and not much else, Travis had explicit steps for Rails…
I actually have the opposite opinion. In game development we care a lot about build systems- and annoyingly, we have vanishingly few companies coming to throw money at our problems. The few that do, charge a kings ransom (Incredibuild). Our build times are pretty long, and minimising them is ideal. If, then, your build system does not understand your build-graph then you’re waiting even longer for builds or you’re ke…
If you're at a games studio that values build-times, value that. I worked at a very good SRE-mindset studio and missed it, deeply, after I left. Back then I expected everyone to think and care about such things and have spent many, many hours advocating for best-in-class, more efficient, cheaper development practices.
WRT github actions... I agree with OOP, they leave much to be desired, esp when working on high-velocity work. My ci/cd runs locally first and then GHA is (slower) verification, low-noise, step.
Re: GitHub Actions is slowly killing engineering teams
#103I hate to say this. I can't even believe I am saying it, but this article feels like it was written in a different universe where LLMs don't exist. I understand they don't magically solve all of these problems, and I'm not suggesting that it's as simple as "make the robot do it for you" either. However, there are very real things LLMs can do that greatly reduce the pain here. Understanding 800 lines of bash is simply…
Additionally it's not like you're constrained to write it in bash. You could use Python or any other language. The author talks about how you're now redeveloping a shitty CI system with no tests? Well, add some tests for it! It's not rocket science. Yes, your CI system is part of your project and something you should be including in your work. I drew this conclusion way back in the days where I was writing C and C++ and had days where I spent more time on the build system than on the actual code. It's frustrating but at the end of the day having a reliable way to build and test your code is not less important than the code itself. Treat it like a real project.
Re: GitHub Actions is slowly killing engineering teams
#104I'll be that guy.
For what boils down to a personal take, light on technicalities, this reads like uncannily impersonal, prolonged attempt at dramatic writing.
If you believe the dates in this blog, it's totally different in tone, style, and wording to a safely distant 2021 post (https://www.iankduncan.com/personal/2021-10-04-garbage-in-ne...).
It made me feel paranoid just in about three paragraphs. I apologize to the author if I'm wrong but we all understand what my gut tells me.
Re: GitHub Actions is slowly killing engineering teams
#105I've used many of the CI systems that the author has here, and I've done a lot of CircleCI and GitHub Actions, and I don't come to quite the same conclusions. One caveat though, I haven't used Buildkite, which the author seems to recommend. Over the years CI tools have gone from specialist to generalist. Jenkins was originally very good at building Java projects and not much else, Travis had explicit steps for Rails…
I actually have the opposite opinion. In game development we care a lot about build systems- and annoyingly, we have vanishingly few companies coming to throw money at our problems. The few that do, charge a kings ransom (Incredibuild). Our build times are pretty long, and minimising them is ideal. If, then, your build system does not understand your build-graph then you’re waiting even longer for builds or you’re ke…
Also game dev here - I disagree with your take. Our _build tools_ need to be hyper aware but our CI systems absolutely do not and would be better served as general purpose. What good is Horde when you need to deploy your already packaged game to steam via steamcmd, or when you need to update a remote config file for a content hotfix. Horde used BuildGraph meaning you need a full engine sync’ed node to run curl -X POST whatever.com
Game dev has a serious case of NIH - sometimes for good reasons but in lots of cases it’s because things have been set up in a way that makes changing that impractical. Using UBA as an example - FastBuild, Incredibuild, SNDBS Sccache all exist as either caching or distribution systems. Compiling a game engine isn’t much different to compiling a web browser (which ninja was written for).
I’ve worked at two game studios where we’ve used general purpose CI systems and been able to push out builds in (I worked for epic when horde came online, but don’t any more).
Re: GitHub Actions is slowly killing engineering teams
#106The 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…
This line of thinking inspired me to write mkincl [0] which makes Makefiles composable and reusable across projects. We're a couple of years into adoption at work and it's proven to be both intuitive and flexible. [0]: https://github.com/mkincl/mkincl
I think the README would be better with a clearer, up-front explanation of what this builds on top of using `make` directly.
Re: GitHub Actions is slowly killing engineering teams
#107The 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…
I agree, but this is kind of an unachievable dream in medium to big projects. I had this fight for some years in my present work and was really nagging in the beginning about the path we were getting into by not allowing the developers to run the full (or most) of the pipeline in their local machines… the project decided otherwise and now we spend a lot of time and resources with a behemoth of a CI infrastructure bec…
Sometimes the problem is that the project is bigger than it needs to be.
Re: GitHub Actions is slowly killing engineering teams
#108Re: GitHub Actions is slowly killing engineering teams
#109I'll be that guy. For what boils down to a personal take, light on technicalities, this reads like uncannily impersonal, prolonged attempt at dramatic writing. If you believe the dates in this blog, it's totally different in tone, style, and wording to a safely distant 2021 post ( https://www.iankduncan.com/personal/2021-10-04-garbage-in-ne... ). It made me feel paranoid just in about three paragraphs. I apologize to…
I also sense an LLM vibe in this post.
Re: GitHub Actions is slowly killing engineering teams
#110At which point did someone force OP to use GH Actions ?
It's fantastic for simple jobs, I use it for my hobbyist projects because I just need 20 to 30 lines to build and deploy a web build.
Just because a bike isn't good for traveling in freezing weather doesn't mean no one should own a bike.
Pick the right tool for the job.
Plus CI/CD is the boring part. I always imagined GH Actions as a quick and somewhat sloppy solution for hobbyist projects.
Not for anything serious.