The tools you just mentioned are not quite the same as this one. Though they belong to this wide “testing” area. Also you of course can write tests on any programming language but you are going to do a lot of low level coding in this case.

DTAP is more for people like devops or operations not willing to do such a heavy lifting job. They just use existing check rules in plain Bash scenarios.

To create new checks knowledge of underlying Sparrow dsl - is required , however to use DTAP you don’t need such a knowledge. Sparrow dsl from other hand provides powerful and flexible mechanisms to deal with complexity of regexp and text patterns search, parsing and validation.

So long story short the tool is beneficial for test users and test ( check rules ) developers so they can leverage existing primitives whether these are check rules or Sparrow task check DSL

I mean if it happens when two different repos would run builds simultaneously. Usually average team may have few repos . If there is no builds at all , I think it’s even less by RAM - as all the dependencies are pretty much in binary complied form - so , say 2 GB would be enough . As backend is pure go ( echo framework ) and is extremely low footprint and as for the CI runner is just a dispatcher background process gets run by very efficient rakupp and just idling . All the git operations are also very lightweight - native smart http / CGI protocol is in use under the hood if you need details

Ok, what requirements you think is lightweight ? We talk about team work anyway , where concurrent builds run …

Even though you’d prefer do everything in cli which is arguable alternative , what about cicd part? Teams need that one

Hey. My too cents here. I am building DSCI - self hosted git with ci embedded . Suitable for small teams with limited VPS hosting, features:

• general programming languages for ci ( not YAML )

• super simple install and maintaining- everything is a single binary ( golang ) , ci jobs run on localhost/podman/docker

• no need extra runners / k8s / devops teams - everything is in dev hands through regular programming code - super simple

• ci SDK is available for bash/python/perl/raku/php/powershell/golang

It’s still in early development stage , but users can already play with it - here is demo stand - http://dsci.sparrowhub.io/

Documentation is available here - http://deadsimpleci.sparrowhub.io/ or GitHub - https://github.com/melezhik/DSCI

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