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

51–60 of 219 posts

Re: GitHub Actions is slowly killing engineering teams

#51

Post by fmjrey »

Nice write up, but wondering now what nix proposes in that space.

I've never used nix or nixos but a quick search led me to nixops, and then realized v4 is entirely being rewritten in rust.

I'm surprised they chose rust for glue code, and not a more dynamic and expressive language that could make things less rigid and easier to amend.

In the clojure world BigConfig [0], which I never used, would be my next stop in the build/integrate/deploy story, regardless of tech stack. It integrates workflow and templating with the full power of a dynamic language to compose various setups, from dot/yaml/tf/etc files to ops control planes (see their blog).

[0] https://bigconfig.it/

Re: GitHub Actions is slowly killing engineering teams

#52

Post by BoorishBears »

mitchjj wrote: post #43
BoorishBears wrote: post #27

Earlier quoted context omitted.

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…

Hello mate, Head of Brand and Design at BK here. Thanks for the feedback, genuinely; the homepage experiment has been divisive, in a great way. Some folk love it, some folk hate it, some just can't be bothered with it. All fair. Glad that the classic site hit the mark, but a lot work to do to make that clearer than it is; we're working on the next iteration that will sunset the CLI homepage into an easter egg. Happy…

Great of you to accept critiques, but I don't think there's anything more I can add.

You brought up Planetscale's markdown homepage rework in one of those posts and I actually think it's great... but it's also clear, direct, and has no hidden information.

I'd love to see what happens to conversions once you retire this to an Easter Egg.

Re: GitHub Actions is slowly killing engineering teams

#54

Post by otterley »

kortex wrote: post #41
anttiharju wrote: post #22

Earlier quoted context omitted.

What pains are you experiencing? Cdk has far exceeded Ansible and Terraform in my experience.

Hooo boy where do I begin? Dependency deadlocks are the big one - you try to share resource attributes (eg ARN) from one stack to another. You remove the consumer and go to deploy again. The producer sees no more dependency so it prunes the export. But it can't delete the export, cause the consumer still needs it. You can't deploy the consumer, because the producer has to deploy first sequentially. And if you can't d…

> Dependency deadlocks are the big one - you try to share resource attributes (eg ARN) from one stack to another. You remove the consumer and go to deploy again. The producer sees no more dependency so it prunes the export.

I’m a little puzzled. How are you getting dependency deadlocks if you’re not creating circular dependencies?

Also, exports in CloudFormation are explicit. I don’t see how this automatic pruning would occur.

> Deploying certain resources that have names specified (vs generated) often breaks

CDK tries to prevent this antipattern from happening by default. You have to explicitly make it name something. The best practice is to use tags to name things, not resource names.

Re: GitHub Actions is slowly killing engineering teams

#55

Post by dbtablesorrows »

noident wrote: post #34
burnJS wrote: 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.

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.

Re: GitHub Actions is slowly killing engineering teams

#56

Post by jamesfinlayson »

zdw wrote: post #21

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

This so much - I remember migrating from one CI system to another a few years ago - I had built all of our pipelines to pull in some secrets and call a .sh file that did all the heavy lifting. The migration had a few pain points but was fairly easy. Meanwhile, the teams who had created their pipelines with the UI and broken them up in to multiple steps were not happy at all.

Re: GitHub Actions is slowly killing engineering teams

#57

Post by bigstrat2003 »

tcoff91 wrote: post #47
habosa wrote: 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.…

Jenkins had a lot of issues and I’m glad to not be using it overall, but I did like defining pipelines in Groovy and I’ll take Groovy over YAML all day.

Jenkins, like many complex tools, is as good or bad as you make it. My last two employers had rock solid Jenkins environments because they were set up as close to vanilla as possible.

But yes, Groovy is a much better language for defining pipelines than YAML. Honestly pretty much any programming language at all is better than YAML. YAML is fine for config files, but not for something as complex as defining a CI pipeline.

Re: GitHub Actions is slowly killing engineering teams

#58

Post by altmanaltman »

burnJS wrote: 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.

Re: GitHub Actions is slowly killing engineering teams

#59

Post by otterley »

CSSer wrote: post #36

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

The flip side of your argument is that it no longer matters how obtuse, complicated, baroque, brittle, underspecified, or poorly documented software is anymore. If we can slap an LLM on top of it to paper over those aspects, it’s fine. Maybe efficiency still counts, but only when it meaningfully impacts individual spend.
Post reply on HN