Live data from Hacker News

GitHub Actions is slowly killing engineering teams

iankduncan.com

71–80 of 219 posts

Re: GitHub Actions is slowly killing engineering teams

#71
post #25

Dead 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.

Re: GitHub Actions is slowly killing engineering teams

#73
post #16

The internet makes me feel like the only person that doesn't mind Jenkins. Idk it just gets the job done ime.

This. In my experience the people actively disliking it have only ever used Jenkins 1 or somewhy only used freestyle jobs.

There are numerous ways to shoot yourself in the foot, though, and everything must be configured properly to get to feature parity with GHA (mail server, plugins, credentials, sso, https, port forwarding, webhooks, GitHub app, ...).

But once those are out of the way, its the most flexible and fastest CI system I have ever used.

Re: GitHub Actions is slowly killing engineering teams

#74

What I find hardest about CI offerings is that each one has a unique DSL that inevitably has edge cases that you may only find out once you’ve tried it. You might face that many times using Gitlab CI. Random things don’t work the way you think it should and the worst part is you must learn their stupid custom DSL. Not only that, there’s no way to debug the maze of CI pipelines but I imagine it’s a hard thing to achie…

That’s the nice thing about buildkite. Generate the pipeline in whatever language you want and upload as JSON or yaml.

Re: GitHub Actions is slowly killing engineering teams

#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 tool for triggering work.

Re: GitHub Actions is slowly killing engineering teams

#76

What I find hardest about CI offerings is that each one has a unique DSL that inevitably has edge cases that you may only find out once you’ve tried it. You might face that many times using Gitlab CI. Random things don’t work the way you think it should and the worst part is you must learn their stupid custom DSL. Not only that, there’s no way to debug the maze of CI pipelines but I imagine it’s a hard thing to achie…

That’s the nice thing about buildkite. Generate the pipeline in whatever language you want and upload as JSON or yaml.

But do you provide SDKs in the languages? I mean even in gitlab I could technically generate YAML in python but what I needed was an SDK that understood the domain.

Re: GitHub Actions is slowly killing engineering teams

#77

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 reading build logs dozens of times a day. The experience of reading them matters in the way that a comfortable chair matters. You only notice how much it matters after you’ve been sitting in a bad one for six hours and your back has filed a formal complaint.

Having to look mentally ignore ANSI escape codes in raw logs (let alone being unable to unable to search for text through them) is annoying as hell, to put it mildly.

Re: GitHub Actions is slowly killing engineering teams

#78
post #34

Earlier quoted context omitted.

I clicked the article thinking it was about GitLab. Much of the criticism held true for GitLab anyway, particularly the insanely slow feedback loops these CI/CD systems create.

Can't blame gitlab for team not having a local dev setup.

You can though. GHA and Gitlab CI and all the others have a large feature set for orchestration (build matrices, triggers,etc.) that are hard to test on a local setup. Sometimes they interfere with the build because of flags, or the build fails because it got orchestrated on a different machine, or a package is missing, or the cache key was misconfigured, etc.

There are a bunch of failures of a build that have nothing to do with how your build itself works. Asking teams to rebuild all that orchestration logic into their builds is madness. We shouldn’t ask teams to have to replicate tests for features that are in the CI they use.

Re: GitHub Actions is slowly killing engineering teams

#79
post #29

Killing engineer teams? Hyperbole thread titles need to be killed. I find github actions to be just fine. I prefer it to bitbucket and gitlab.

Yeah I was wondering how Microsoft is okay with Github murdering people but then was let down by the article.

[flagged]

Re: GitHub Actions is slowly killing engineering teams

#80
post #78

Earlier quoted context omitted.

Can't blame gitlab for team not having a local dev setup.

You can though. GHA and Gitlab CI and all the others have a large feature set for orchestration (build matrices, triggers,etc.) that are hard to test on a local setup. Sometimes they interfere with the build because of flags, or the build fails because it got orchestrated on a different machine, or a package is missing, or the cache key was misconfigured, etc. There are a bunch of failures of a build that have nothin…

Indeed there are. But you iterate on local and care about CI once everything is working in local. It's not every tuesday I get CI errors because a package was missing. It's rare unless you're in those 1000-little-microservice shops.
Post reply on HN