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
 

DSCI is simple yet super flexible pipeline engine to write CI code on regular programming languages, integrates with Forgejo using web hooks. Intended for small teams hosting Forgejo on single VM VPS and willing to create pipelines on regular programming languages

top 20 comments
sorted by: hot top controversial new old
[–] smaximov@lemmy.world 13 points 1 day ago (2 children)

(no YAML)

looks inside

still has YAML

[–] arran4@aussie.zone 1 points 1 day ago

I mean there is only so many ways of representing a data structurally clearly. I find that yaml is good enough but like XML leads to a lot of bloat, but unlike XML isn't nearly as complicated. I'm not sure making it a library resolves the issue better than creating a custom grammar that appropriately accommodates what people want to express in the language easily, make the possible and desired easy, the impossible and undesirable states hard if not unrepresentable. I mean having a custom language does allow for loops, and functions which isn't something I find I need too much in CI. Perhaps templating / functions but having a full Turing complete language leads the way for bad states / nonideal uses.

[–] melezhik@programming.dev 2 points 1 day ago* (last edited 1 day ago) (1 children)

Only as high level glue , main logic is just normal programming languages - see here https://github.com/melezhik/DSCI/tree/main/examples

[–] FizzyOrange@programming.dev 3 points 1 day ago (1 children)

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.)

[–] melezhik@programming.dev 2 points 1 day ago* (last edited 1 day ago) (1 children)

... put those in separate scripts and call them from the YAML.

This is exactly what I try to avoid, cause:

  1. many people (in my experience ) even don't bother refactoring YAML spaghetti code to separate scripts and we end up unmaintainable codebase

  2. 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 ))

[–] FizzyOrange@programming.dev 1 points 1 day ago (1 children)

and even if one has to do such a refactoring what is the point of using YAML at all ?

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.

[–] melezhik@programming.dev 2 points 1 day ago* (last edited 1 day ago)

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 ))

It allows the CI engine to determine which jobs to start, what their steps are etc.

Yep, like a said , I don't mind to have such a configuration inside YAML, but this should NOT be pipeline code itself )

[–] melezhik@programming.dev 3 points 1 day ago
[–] Valmond@lemmy.dbzer0.com 2 points 1 day ago (1 children)

You can just hit up any other language from it though?

[–] melezhik@programming.dev 2 points 1 day ago* (last edited 1 day ago) (1 children)

Here is SDK for those languages:

Raku Perl Bash Python Ruby Powershell Php Golang

UPDATE: so it's not just hitting up a language from a pipeline , it's full reach SDK, one writes a pipeline on a language, if I get your comment correctly

[–] Valmond@lemmy.dbzer0.com 1 points 1 day ago (1 children)

Well no I mean if you want to do something in python just call up the python interpreter, if you have some existing stuff in TCL, just run it through that interpreter and so on,no need for a specific anything.

[–] melezhik@programming.dev 2 points 1 day ago* (last edited 1 day ago) (1 children)

But now when you have a YAML program as the first level abstraction how do you handle results between those multi language calls ? In DSCI this is achieved via states and normal functions , and everting is just a function on general purpose programming language, in YAML you need all these magic ( awkward ) YAML syntax to mimic all those things ( pass parameters , handle global variables , process user input , handle returned parameters , etc )

[–] Valmond@lemmy.dbzer0.com 1 points 1 day ago

When I did it was just like bash in yaml, return 1/0 from python, TCL, ...

IIRC !

[–] thesmokingman@programming.dev 1 points 1 day ago (1 children)

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?”

[–] melezhik@programming.dev 1 points 1 day ago* (last edited 1 day ago) (1 children)

Ok, try to do it on GH actions, share states between tasks/jobs for example:

tasks/task_one/task.py

#!/usr/bin/python3

update_state({
  'out1' : 'out1 value',
  'out2' : 'out2 value'
})

tasks/task_two/task.py

#!/usr/bin/python3

dict = get_state()
print(dict["out1"])
print(dict["out2"])

Or share states between jobs:

jobs/job1/task.py

#!/usr/bin/python3

update_state({
  'out1' : 'out1 value',
  'out2' : 'out2 value'
})

jobs/job2/task.py

#!/usr/bin/python3

dict = config()

print(dict["_dsci_"]["job1"]["out1"])
print(dict["_dsci_"]["job1"]["out2"])

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:

#!/usr/bin/python3

if some_condition(foo, bar): 
    run_task(
       'task1', {
          'foo' : 'foo value',
          'bar' : 'bar value'
       }
    )

The same could be quite awkward in YAML based code

[–] thesmokingman@programming.dev 1 points 1 day ago (1 children)

This is a boilerplate example. I asked for something more than boilerplate. Give me some reasons why I need an incredibly stateful CI engine.

[–] melezhik@programming.dev 2 points 1 day ago* (last edited 1 day ago) (1 children)

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:

  • creation of virtual machines with dynamic IP addresses
  • creation of bug tracking system tickets with unique ticket IDs
  • looking up in databases where fetched records have unique IDs

etc

[–] thesmokingman@programming.dev 2 points 1 day ago (1 children)

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.

  1. Why wouldn’t you use IaC tools for this? All the majors have Python already.
  2. What build or deploy task needs to both create and reference a bug ticket?
  3. What build or deploy task needs to do database lookups? Or possibly what task needs those across multiple, independent stages?
[–] melezhik@programming.dev 1 points 1 day ago* (last edited 1 day ago)

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 )

[–] Marija_@programming.dev 1 points 1 day ago

Less YAML, more Optimocracy.