141–150 of 179 posts
Earlier quoted context omitted.
Of all the problems with YAML, how is comments a footgun?
> or other affordances
"On the virtues of the trailing comma" https://devblogs.microsoft.com/oldnewthing/20240209-00/?p=10...
Earlier quoted context omitted.
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 e…
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 too…
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.
I probably would have made the same mistake. It is negligent to write GitHub Actions without using static analysis. Use zizmor in CI https://github.com/zizmorcore/zizmor error[template-injection]: code injection via template expansion --> .github/workflows/jira_issue.yml:24:29 | 22 | run: | | --- this run block 23 | # Escape special characters in title and body 24 | TITLE=$(echo '${{ github.event.issue.title }}' | se…
Shell scripts on their own already are so perilous without static analysis. I'll never understand how we ended up deciding that embed them in yaml instead of requiring an external script file was a reasonable idea.
I probably would have made the same mistake. It is negligent to write GitHub Actions without using static analysis. Use zizmor in CI https://github.com/zizmorcore/zizmor error[template-injection]: code injection via template expansion --> .github/workflows/jira_issue.yml:24:29 | 22 | run: | | --- this run block 23 | # Escape special characters in title and body 24 | TITLE=$(echo '${{ github.event.issue.title }}' | se…
YAML is a nightmare fuel spec. In its quest to make markup "human readable", it has created countless footguns. I honestly prefer XML at this point.
Earlier quoted context omitted.
Seems more like the opposite vein, JSON's lack of comments or other affordances has kept it safe from footguns
Of all the problems with YAML, how is comments a footgun?
> a single quote in the title breaks out of echo '...' and allows arbitrary command execution. Quote injection still alive and well in 2026. Gawd.
I probably would have made the same mistake. It is negligent to write GitHub Actions without using static analysis. Use zizmor in CI https://github.com/zizmorcore/zizmor error[template-injection]: code injection via template expansion --> .github/workflows/jira_issue.yml:24:29 | 22 | run: | | --- this run block 23 | # Escape special characters in title and body 24 | TITLE=$(echo '${{ github.event.issue.title }}' | se…
Shell scripts on their own already are so perilous without static analysis. I'll never understand how we ended up deciding that embed them in yaml instead of requiring an external script file was a reasonable idea.
That's critical for a platform like GitHub and for devops pipelines in general.
The failure is that "data" ends up being a "terrible custom DSL" that is bad at everything: Not good at data, not a good DSL, and not even a proper programming language.
The best approaches I have seen to this kind of thing are:
- Pulumi: You get to run custom code, but it outputs data. In other words, your "build automation script" must be a pure function taking data in and returning data out. The resulting data is then treated as the "thing" that the pipeline executes, which means that all decisions (parameters, inputs, etc...) have to be "baked in", before the pipeline starts executing.
- Google CUE (Configure Unify Execute): lets you build up JSON using a strongly typed constraint language. Great for huge, complex configuration.
YAML is a nightmare fuel spec. In its quest to make markup "human readable", it has created countless footguns. I honestly prefer XML at this point.
I never figured out how the hell to write YAML and I definitely won't now that I trust the AI to do a better job than me. It's so unintuitive. Every time I've tried in the past, something as simple as making a value a list had some nonsense expectations. I can't wrap my head around how that spec got any traction and wasn't laughed off the face of the earth the first time it was looked at by someone who didn't create…
Earlier quoted context omitted.
In a similar vein, JSON's lack of comments makes me marvel at how consistently JavaScript seems to choose the worse option. I'm oh so glad it found its way into config files
As a data/serialization format (the original intended use of JSON), I think no comments is the right choice, since adding comments introduces a bunch of questions about how comments ought to be parsed into a datastructure (or if they should be sent/(de)serialized at all). But for config files the lack of comments is the wrong choice, since typically you want to explain why things are set the way they are. The lack of…