GitHub Actions isn’t killing engineering teams; complacency in CI design is. CI should be reliable, inspectable, and reproducible, not just convenient.
GitHub Actions is slowly killing engineering teams
141–150 of 219 posts
Re: GitHub Actions is slowly killing engineering teams
#142> If you’re a small team with a simple app and straightforward tests, it’s probably fine. I’m not going to tell you to rip it out. > But if you’re running a real production system, if you have a monorepo, if your builds take more than five minutes, if you care about supply chain security, if you want to actually own your CI: look at Buildkite. Goes in line with exactly what I said in 2020 [0] about GitHub vs Self-hos…
I know this is off topic, but that homepage is a piece of work: https://buildkite.com I get it's quirky, but I'm at a low energy state and just wanted to know what it does... Right before I churned out, I happened to click "[E] Exit to classic Buildkite" and get sent to their original homepage: https://buildkite.com/platform/ It just tells you what it Buildkite does! Sure it looks default B2B SaaS, but more important…
oh wow, that's not good.
Re: GitHub Actions is slowly killing engineering teams
#143The 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…
Ye, kick off into some higher-level language instead of being at the mercy of your CI provider's plugins.
I use Fastlane extensively on mobile, as it reduces boilerplate and gives enough structure that the inherent risk of depending on a 3rd-party is worth it. If all else fails, it's just Ruby, so can break out of it.
Re: GitHub Actions is slowly killing engineering teams
#144Earlier quoted context omitted.
Funny enough, the LLMs are allowed to run builds on your local machine. The humans, not any more.
But it isn't a question of security. The project would very much like the developers to be able to run the pipelines on their machines. It's just that management don't see it as worth it, in terms of development cost and limitations it would introduce in the current workflow, to enable the developers to do that.
> But it isn't a question of security.
Where did i mention security?
> in terms of development cost and limitations it would introduce in the current workflow
Well said. "in the current workflow". As in, not "in the development process". Those are unrelated items.
Re: GitHub Actions is slowly killing engineering teams
#145Earlier quoted context omitted.
That’s the nice thing about buildkite. Generate the pipeline in whatever language you want and upload as JSON or yaml.
JSON or YAML imply a buildkite DSL as there's no standard JSON or YAML format for build scripts
I assume by DSL they mean some custom templating language built on top, for things like iterating and if-conditions. If it's plain JSON/YAML you can produce that using any language you wish.
Re: GitHub Actions is slowly killing engineering teams
#146I 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.…
The "just keep your CI simple" mindset doesn't work in practice. Any non-trivial project will have a high chance that it'll have to encode some form of logic in the CI, either for situational triggers, or git branching strategies, on demand deployments, permissions, secrets, heterogeneous runners, load balance, local testing, component testing... these are all valid use-cases, all with their own gotchas and hard-to-debug issues in all CI systems I know.
It's correct to design CI pipelines in order to offload much of the logic to subsystems, but pipelines will eventually grow in complexity and the CI config system should be designed in order not to get in the way. I don't know buildkite, but Gitlab CI is the best I know. Template and job composition works brilliantly, top-level object being the job and not the stage result in flat, easier to read config files and the packed features are really good, but it's hard to debug, the conditional logic sometimes fails in unexpected ways, it's exhausting to use the predefined variables reference and the permission system for multi project pipelines is abysmal.
Re: GitHub Actions is slowly killing engineering teams
#147We all have opinions about ci/cd. Why? Because it's getting between us and what we're attempting to do. In all honesty GitHub actions solves the biggest problem for a lot of Devs, infrastructure management and performance. I have managed a lot of build infrastructure and don't ever want to touch that again. GitHub fixed that for me. My build servers were often more power hungry than my production servers. GitHub fixed that for me. Basically what I'm saying is for 80% of people this is an 80% good enough solution and that's more important than everything else. Can I ship my code quickly. Can I define build deps next my code that everyone can see. Can I debug it, can others contribute to it. It just ticks so many boxes. I hope ci dies a good death because I think people are genuinely just thinking about the wrong problem. Stop making your life more difficult. Appreciate what this solves and move on. We can argue about it until we're blue in the face but it won't change the fact that often the solution that wins isn't the best, it's the one that reduces friction and solves the UX problem. I don't need N ways to configure somehow. I need to focus on what I'm trying to ship and that's not a build server.
Re: GitHub Actions is slowly killing engineering teams
#148Dead on. GitHub Actions is the worst CI tool I’ve ever used (maybe tied with Jenkins) and Buildkite is the best. Buildkite’s dynamic pipelines (the last item in the post) are so amazingly useful you’ll wonder how you ever did without them. You can do super cool things like have your unit test step spawn a test de-flaking step only if a test fails. Or control test parallelism based on the code changes you’re testing.…
what's wrong with Jenkins? It's battle tested and hardened. Works flawless even with thousands of tasks, and WORKS OUT OF THE BOX. imo top 10 best admin/devs free software written in past 25 years.
It's too old and easy-to-use for anyone to hype it up as the next cool thing.
Re: GitHub Actions is slowly killing engineering teams
#149The log viewer thing is what baffles me most. Back in... I don't know, 2010, we used Jenkins. Yes, that Java thingy. It was kind of terrible (like every CI), but it had a "Warnings Plugin". It parsed the log output with regular expressions and presented new warnings and errors in a nice table. You could click on them and it would jump to the source. You could configure your own regular expressions (yes, then you have…
The only thing I can understand is that GHA is awesome because it's YAML and everyone loves YAML. Irrationally. YAML is terrible.
GHA is hosted, works well-enough, and you already pay a github bill so you don't need to onboard a new vendor.
Re: GitHub Actions is slowly killing engineering teams
#150After troubleshooting a couple issues with the GitHub Actions Linux admin team, and their decision to not address either issue, I'm highly skeptical of investing more in GitHub Actions:
- Ubuntu useradd command causes 30s+ hang [1]
- Ubuntu: sudo -u some-user unexpectedly ends up with environment variables for the runner [2]