this post was submitted on 24 Jul 2026
23 points (96.0% liked)
Programming
27841 readers
753 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
Looking at the examples, you’ve just made a brand new GitHub Actions framework. There’s YAML to wrap everything together and a bunch of Python that’s so declarative it might as well be HCL. Do you have an example that’s a bit more than “do what YAML does only in bash?”
Ok, try to do it on GH actions, share states between tasks/jobs for example:
tasks/task_one/task.py
tasks/task_two/task.py
Or share states between jobs:
jobs/job1/task.py
jobs/job2/task.py
I can't imagine how much boilerplate code (if this ever possible ) one needs to write to achieve that on YAML based pipelines (GH Actions/ etc)
And don't tell me about jobs artifacts ))
UPDATE:
Another good example is to run tasks conditionally, yes using old good
if:The same could be quite awkward in YAML based code
This is a boilerplate example. I asked for something more than boilerplate. Give me some reasons why I need an incredibly stateful CI engine.
it's just because I think in real world we have a lot of tasks where state is required or extremely beneficial, some examples on top of my head:
etc
I wouldn’t do any of that in a CI-only system. If I did, I’d use tools that exist for those jobs that already allow scripting languages.
If you use tools gluing them into YAML - you get YAML bloated with time . When you say those tools already having Python - excellent I would like to use those Python libs or SDK directly in my Python code instead of juggling those tools as cli or code blocks inside YAML
UPDATE: and yeah , re-read again - I guess the most of automation is done today via “CI” pipelines even when those are not meant to be CI only, like you said … anyways the rest I have said stands true for me … don’t bake your code into YAML )