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

211–219 of 219 posts

Re: GitHub Actions is slowly killing engineering teams

#211

Post by Marsymars »

Storment33 wrote: post #210
Marsymars wrote: post #199

Earlier quoted context omitted.

> I would also question why your adding users on an ephemeral runner. We use runners for things that aren't quite "CI for software source code" that does some "weird" stuff. For instance, we require that new developer system setup be automated - so we have a set of scripts to do that, and a CI runner that runs on those scripts.

Fair enough if you've some development environment automation and you want the CI to run it as well so CI is consistent with local development. Don't know exactly what your doing but others(myself included) are using Mise or Nix on a per project basis to automate the development environment setup and that works well on GitHub Actions. But I don't think useradd taking 30's on GitHub Actions is a bug or something they…

> Fair enough if you've some development environment automation and you want the CI to run it as well so CI is consistent with local development.

Oh we don't even run it in applications' CI, the environment automation is an entirely separate CI workflow. The intention isn't consistency between dev/CI, the environment automation CI effectively just serves to ensure that the automations actually run without error, and adds some explicit responsibility for anyone who's adding a new dependency.

> But I don't think useradd taking 30's on GitHub Actions is a bug or something they need to fix, they've explained why. Unsure about the sudo issues, did not read it carefully.

Yeah, agreed. Tangential, our dev setup CI is fairly slow, which tends to be fine - it runs a couple orders of magnitude less frequently than our app CI.

Re: GitHub Actions is slowly killing engineering teams

#212

Post by mitchjj »

jjgreen wrote: post #209
mitchjj wrote: post #188

Earlier quoted context omitted.

Understandable; let me ask a a question. You don't want to play these sort of games (read a paragraph, enter a word). For you, browsing to find a compelling devtool, what makes you say, this is legit? Can you share examples of a couple of sites that do exactly what you are after? I say that not because we wanted the CLI homepage to be 'legit', the light context there is we needed a way to quickly change direction fro…

I'd never heard of BK before and I see some positive opinions on HN; I manage a small company's CI, we're really rather happy with GitLab CI, but I'm always on the lookout for something better. Clicking through to your page I'm looking to quickly find out what are the features, why it's different, how much it costs ... and for that a boring, routine website is what I'm hoping for. I'm very much not against the comman…

Nah that's great, and valuable. I hear you on, boring and routine likely facilitates further digging. Thanks for taking the time, I appreciate it!

Re: GitHub Actions is slowly killing engineering teams

#213

Post by kortex »

otterley wrote: post #54
kortex wrote: post #41

Earlier quoted context omitted.

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

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

I explained that. It's a quirk of how it tree-shakes, if nothing dereferences the attribute, it deletes the export. And yes it'll automatically create an export if you do something like

    environment={"table": parent_stack.table.table_arn}
> 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.

I'm well aware but i'm fighting a ton of institutional inertia at my work.

Re: GitHub Actions is slowly killing engineering teams

#214

Post by pluto_modadic »

slackfan wrote: post #5

All CI is just various levels of bullshit over a bash script anyway.

This is kinda... rude. Like saying that a GUI doesn't serve a purpose when people could read the TTY.

CI gives you areas for your bash scripts to run in self-contained small runs, that may trigger other runs, in a repeatable fashion on a clean environment, on a GUI anybody in your team can see. It gives you quick integrations into things.

CD lets you repeatedly deploy - without forgeting a step that was only known to Phil, the guy that retired three years ago, remembering all the steps and doing something dependably.

Or... you could do bash scripts? https://www.youtube.com/watch?v=40SnEd1RWUU (Just use a VPS, bro)

Re: GitHub Actions is slowly killing engineering teams

#215

Post by crohr »

> You know how I know GitHub’s runners are bad? Because there’s an entire cottage industry of companies whose sole product is “GitHub Actions, but the runners don’t suck.” Namespace, Blacksmith, Actuated, Runs-on, BuildJet

He's not wrong. Buildjet just announced they were shutting down though, citing recent improvements to the GitHub Actions platform.

For the record I maintain the Runs-on [1] he's talking about, as a solo developer.

[1] https://runs-on.com

Re: GitHub Actions is slowly killing engineering teams

#216

Post by ycombiredd »

jimmcslim wrote: post #84

Pour one out for the memory of CruiseControl, the OG (?) granddaddy of all CI systems in the form we would recognise them today.

I remember setting up CruiseControl when I was at a J2EE shop. That and Mantis, but I don't remember which was before which.

Re: GitHub Actions is slowly killing engineering teams

#217

Post by davidboar »

mcv wrote: post #68

I don't have much experience with Guthub Actions, but I'll say this does sound worse than Azure DevOps, which I did not imagine was possible. I've never liked any CI system, but ADO must be one of the lower circles of hell.

It really isn't worse than ADO. I suspect the author has not been subjected to ADO, or he'd have literally exploded given this is the way he feels about GHA.

Re: GitHub Actions is slowly killing engineering teams

#218

Post by davidboar »

secult wrote: post #91

I think Github Actions is just a lead for Microsoft customers to use paid Azure DevOps. It is bad intentionally.

ADO is far worse in every conceivable way. It lends itself to utterly byzantine dependency trees for the CI definitions, and also makes it very complex to set permissions to prevent pipelines running from branches with the same permissions as the protected branch.

Re: GitHub Actions is slowly killing engineering teams

#219

Post by olafmol »

kdazzle wrote: post #39

Pretty sure someone at MS told me that Actions was rewritten by the team who wrote Azure DevOps. So bureaucracy would be a feature. That aside, GH Actions doesn’t seem any worse than GitLab. I forget why I stopped using CircleCI. Price maybe? I do remember liking the feature where you could enter the console of the CI job and run commands. That was awesome. I agree though that yaml is not ideal.

Debug with SSH(1) is still one of our (CircleCI) most loved and praised features. I really believe that these little QoL features can make a world of difference for sw developers and engineers, and this stays a strong focus for us.

1: https://circleci.com/docs/guides/execution-managed/ssh-acces...

(Disclaimer: i work at CircleCI)

Post reply on HN