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
(no YAML)
looks inside
still has YAML
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
#!/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
This is a boilerplate example. I asked for something more than boilerplate. Give me some reasons why I need an incredibly stateful CI engine.