Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Actions is slowly killing engineering teams

iankduncan.com

Post reply on HN
Print view View original

81–90 of 219 posts

Re: GitHub Actions is slowly killing engineering teams

#81

Post by usr1106 »

dataflow wrote: post #77
danpalmer wrote: post #10

I'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…

> but... the log browser? So what, just download the file, at least the CI works. They answer your "so what" quite directly: >> Build logs look like terminal output, because they are terminal output. ANSI colors work. Your test framework’s fancy formatting comes through intact. You’re not squinting at a web UI that has eaten your escape codes and rendered them as mojibake. This sounds minor. It is not minor. You are…

Doesn't `less -R` solve the ANSI escape problem?

Re: GitHub Actions is slowly killing engineering teams

#82

Post by wtcactus »

Happy user of GitLab CI here.

I see the appeal of GitHub for sharing open source - the interface is so much cleaner and easier to find all you are looking for (GitLab could improve there).

But for CI/CD GitHub doesn’t even come close to GitLab in the usability department, and that’s before we even talk about pricing and the free tiers. People need to give it a try and see what they are missing.

Re: GitHub Actions is slowly killing engineering teams

#83

Post by wtcactus »

mickeyp wrote: post #75

The 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 because each MR takes about 10 builds (of trial and error) in the pipeline to be properly tested.

Re: GitHub Actions is slowly killing engineering teams

#86

Post by bugglebeetle »

anttiharju wrote: post #17

Github being less and less reliable nowadays just makes this more true. In the past week I have seen: - actions/checkout inexplicably failing, sometimes succeeding on 3rd retry (of the built-in retry logic) - release ci jobs scheduling _twice_, causing failures, because ofc the release already exists - jobs just not scheduling. Sometimes for 40m. I have been using it actively for a few years and putting aside everyth…

Yeah, do crons even work consistently for GitHub Actions? I tried to set one up the other day and it just randomly skipped runs. There were some docs that suggested they’re entirely unreliable as well.

Re: GitHub Actions is slowly killing engineering teams

#87

Post by dijit »

danpalmer wrote: post #10

I'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 keeping around incremental state and dirty workspaces (which introduces transient bugs, as now the compiler has to do the hard job of incrementally building anyway).

So our build systems need to be acutely aware of the intricacies of how the game is built (leading to things like UnrealEngine Horde and UBA).

If we used a “general purpose” approach we’d be waiting in some cases over a day for a build, even with crazy good hardware.

Re: GitHub Actions is slowly killing engineering teams

#88

Post by mickeyp »

wtcactus wrote: post #83
mickeyp wrote: post #75

The 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…

It's not an unachievable dream. It's a trade-off made by people who may or may not have made the right call. Some things just don't run on a local machine: fair. But a lot of things do, even very large things. Things can be scaled down; the same harnesses used for the development environment and your CI environment and your prod environment. You don't need a full prod db, you need a facsimile mirroring the real thing but 1/50th the size.

Yes, there will always be special exemptions: they suck, and we suffer as developers because we cannot replicate a prod-like environment in our local dev environment.

But I laugh when I join teams and they say that "our CI servers" can run it but our shitty laptops cannot, and I wonder why they can't just... spend more money on dev machines? Or perhaps spend some engineering effort so they work on both?

Re: GitHub Actions is slowly killing engineering teams

#89

Post by carlsmedstad »

mickeyp wrote: post #75

The 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

Post reply on HN