this post was submitted on 24 Jul 2026
23 points (96.0% liked)
Programming
27824 readers
566 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
You can (and should!) do exactly the same with "traditional" GitHub Actions style YAML.
Avoid putting commands in the YAML - put those in separate scripts and call them from the YAML. The YAML should only be used for things that can't be done from scripts (e.g. job matrices, uploading artifacts, reporting status etc.)
This is exactly what I try to avoid, cause:
many people (in my experience ) even don't bother refactoring YAML spaghetti code to separate scripts and we end up unmaintainable codebase
and even if one has to do such a refactoring what is the point of using YAML at all ?
All I need just a collection of tasks/jobs written on languages of choice and I don't need YAML "programming" language at all )
PS And btw I don't mind having a minimal amount of YAML as configuration layer and this is what is presented in DSCI, but only minimal ))
It allows the CI engine to determine which jobs to start, what their steps are etc.
To be fair I have worked on one project that had very complex CI and we almost decided to generate the CI graph procedurally with a Python script (Gitlab supports this, somewhat awkwardly). But in the end we decided it wouldn't be worth the overhead of writing, maintaining and learning a whole new CI system on top of Gitlab's CI.
The issues you had just proves that YAML based CI approach always leads to troubles with time. And yeah, I have been there, code generators for YAML. Hundreds of lines for YAML pipelines, etc ))
Yep, like a said , I don't mind to have such a configuration inside YAML, but this should NOT be pipeline code itself )