Hacker News Reader

Comment by doix | Hacker News Reader

Yeah, the YAMLification of everything kinda killed my ability to understand "everything". Previously, if you knew the Linux userland well, I felt like you could figure anything out with enough digging.

Take CI for example, it was Jenkins and it ran a csh/bash/zsh whatever script and captured the output. Nice and simple (even if the scripts sometimes got insane).

GitHub actions is nothing like that. Weird home grown extensions to YAML with their own idiosyncrasies and dynamically pulling in plugins from god knows where. You can't just take a workflow and execute it locally like you could with a bash script.

View on HN

And worse: GitHub Actions not a full-fledged programming environment by itself either, so you're inevitably going to have to deal with nontrivial shell scripts on top of all the YAML mess.

Yeah. It makes sense when you're standing right next to it, but you take a step back and go "that doesn't look right". GitHub actions is the faster horse instead of a car.

The things done in yaml today would've been obscure bash oneliners had YAML not existed.

Jenkins still exists and it's no less complicated than Github Actions. The complexity gets hidden in obscure script files, obscure tabbed UI, and remote services for doing things Jenkins itself can't do. Defaulting to system tooling makes it almost impossible to predict what a job will do unless you know exactly how paths and tooling are set up (and what versions they're running).

None of my personal experiences with Jenkins had scripts that ran locally, they all relied on pre-installed software on the server because that was the thing people would do before the great YAMLification. You could copy-paste the Jenkins job, but unless you have Jabberwocky v2018.3 installed in /home/JabberWock/RELEASE, the script will fail.

The entire software development flow has been made incredibly complex by hooking up automations into every nook and cranny.

All of these complications need to be enabled manually, though. If your flow is complicated, you can cut it down to manageable size by doing a few more processes manually.

Luckily, all of the simplication and reproduction steps for Github also apply to Jenkins. Github YAML files are just scripts with different syntax, after all. Just like you can run bash locally, you can run act and reproduce whatever Github trigger you need. From there, you can simplify pipelines, stop curl2bashing "plugins", and so on.

> You could copy-paste the Jenkins job, but unless you have Jabberwocky v2018.3 installed in /home/JabberWock/RELEASE, the script will fail.

In my experience, containerization resolved this issue. Now you just need to be able to "docker run public.ecr.aws/carroll/jabberwocky:v2018.3 [etc]".

And in Github that would be something like:

    steps:
    - name: Run jabberwocky
      run: docker run -it public.ecr.aws/carroll/jabberwocky:v2018.3 [etc]

Except that YAML in almost every devops or CI workflow is YAML plus obscure bash oneliners.

Or it's an obscure bash oneliner hidden in another repository as a package that you can depend on, which is either wrapped by another YAML config or maybe some JS.

I don't think the criticisms of Jenkins compare because Jenkins is really much more than a CI layer, predates the concept of devops and our modern understanding of CI/CD, and it has a lot of complexity to make that work. That was back when you'd have IT teams provisioning your servers for you and shit.

> in almost every devops or CI workflow

But that's the core of the problem, isn't it? People setting up devops environments are the reason these flows are so complicated. You can set up the same flows by having Jenkins call out to Jenkins to trigger chains of jobs that can conditionally fail.

People generally don't do it, because there are better alternatives out there for when you want those types of pipelines (which includes Github Actions and their counterparts). Setting up a four-step build+test+scan+tag+push+deploy pipeline in Jenkins is just as hard as it is with Github, if not harder. [Jenkinsfile](https://www.jenkins.io/doc/book/pipeline/jenkinsfile/) is just YAML with extra parentheses.

The modern YAML files are a simplification of the manual steps required to do it all in tools that predated the YAML files. There's nothing stopping you from having a Github runner configuration that's just a call to a single Docker image containing all the bash/perl/Makefile/Kotlinscript/Go/Ruby/etc. files you want to execute. Or you can forego the Docker part and run code directly inside of the repository, with all the security risks that come with it (not dissimilar to having a fully open Jenkins server).

Complicated YAML is a symptom. It's no better or worse than Bash or TOML or Makefile when you start adding conditional automation and multi-step CI/CD flows.

You are not wrong, Jenkins had many problems. But I would argue that the solutions were always grounded in the Linux userland.

And I also agree that you could use GitHub actions in a similar way to how I talk about Jenkins. I also think you could use Jenkins in a way that is similar to GitHub actions with an extremely convoluted Jenkins file that relies on Jenkins plugins etc.

But nowhere I worked did that with Jenkins, whereas everywhere I worked with GitHub actions does create extremely complex pipelines relying on 3rd party actions (with many being vendor supplied). I'm sure(hope?) the DevOps folks looked at what each action actually does by going to wherever it's pulled from and read it (and the actions it pulls in).

I'm not necessarily arguing that things are worse now. Just that you don't get a "free" understanding anymore by just having a good familiarity of the Linux userland. When there's a problem, I stick my head in the sand and let the DevOps people handle it.

I also haven't worked anywhere that uses Jenkins in 10+ years, so maybe if I went back, it would be the same as Github.

Lack of a local runner is my biggest peeve. Any novel GHA workflow creation results in a PR with 100 commits, until you can finally sort out all the non-obvious idiosyncrasies. For any modestly complex workflow, I move everything to a bash or TS file and call that, and then you can use _coding tools_ and a _local_ dev/eval loop.

How funny that GitHub Actions' lack of tools forces you to make a bunch of billed cloud runs with GitHub for workflow edits. I'm sure their PMs are very concerned about this trend.

A local runner would certainly help, but only to some extend. When you need to support multiple OS (Windows, Linux, macOS) and architecture (x64, arm64), not everything can be tested locally.

Try writing a regression test for your Github Action.. I'll wait.

It's a pretty ridiculously half-baked feature. But a lot of these devtools are--it's arguably even worse in the observability vertical. You have all these metrics and dashboards you're using to make critical business and operational decisions yet no way to actually ensure they're telling you what you think they are. Clown shit.

Reply on news.ycombinator.com