GitHub actions must have eaten most of the DevOps tooling market. It’s pretty good and it’s fine for the vast majority of pipelines.

GH Actions is just CI, maybe crude CD, and not the best at that.

It and (GitLab CI) ate Jenkins

Jenkins still does stuff that you can't do with GH Actions. Actions ate Travis / TeamCity / CircleCI, all the "more polished Jenkins for the 80% use case" products.

What does Jenkins do that you can't do with GH Actions and Flux?

Based on the last time I looked: good handling of dependencies between builds (e.g. the ability to do an "edge build" where for any change in a given project, you check whether that will break your other projects when they upgrade to depend on that), advanced scheduling, plugins that integrate all sorts of random tools into your build views.

I have been away from Jenkins for a while, that all sounds like stuff I never used, (thanks!)

Hell, we do it once in terraform/pulumi/cdk and then it takes 10 minutes to tweak some variables and switch aws accounts and bam

Our devs/SRE put up apps and clusters in minutes (aside from the terrible alb/ecs/eks/etc deployment times).

Yeah this is nice if you have large teams and repeatable projects. Smaller companies have much more ad-hoc requests. I stood up an entirely new type of project end-to-end from a docker compose into our cluster. Re-used alot of code base but it was still a bit of work. Much less than it used to be though.

I have this installed but I've never actually done more than a quick test of it but this might be a good tool for you. It'll record all of your aws console actions and output them as terraform, couldformation, cdk, etc.

That'd give you a repeatable deployment for disaster recovery without having the toil of writing that part of it. Having to click through every checkbox in the console and iam perms and blahblah under fire is rough.

https://chromewebstore.google.com/detail/console-recorder-fo...

This.

We looked at weaveworks and its competitor both as a product and an investment (mid 6 figure usage). Our big issue was that we had a lot of smaller teams doing different things and not one or two featured items raking in the majority of our revenue.

These solutions work if you have a bunch of snowflake workloads by design (or bad design).

> a bunch of snowflake workloads by design (or bad design).

That's a really interesting characterization of WGE, and I can't say I disagree much (my personal opinion as an ex-Wyvern/OSS Engineer DX @ weaveworks)

Yeah I literally did this last week for a new in house AI assistant for my company. Just swap out Jenkins for GH actions (sadly). So... can confirm.

How does your pipeline work with an app that requires many other services to work?

Your GitHub action can trigger a helm chart, or series thereof, or other infra tools. Declarative specifications, triggered procedurally with the context of the branch’s latest build. We use this pattern quite extensively for preview app workflows.

As of a year ago this is possible in a fully declarative way with Flux 2, but there’s a lot more moving parts and security footguns - and the idea that the maintenance of this project has lost one of its primary sponsors is worrying at best.

https://github.com/fluxcd/flux2/discussions/831

https://blog.kluctl.io/introducing-the-template-controller-a...

> a CICD pipeline that does per-PR namespace isolated deploys of an app stack on EKS using Github actions... [with] docker compose for local testing

Please teach me, oh wise prince!

<7000 lines of cut / paste YAML later> “it’s that easy!”

I'd love to see 7K of YAML as every time I've asked, no one's been able to show me a fully worked, end-to-end example.

they did more than just CICD but I see your point.