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

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

GH project link - https://github.com/melezhik/doubletap for ones who are curious

This seems, at best, some general security checks but not mapped to any framework in particular.

So. Yes. Ssh access should be passwords only, etc. Some common sense. We don’t need standard to that

UPDATE: sorry for the typo, meant passwordless

The plan is to build the entire system on top of Sparky which is written on Raku and extended by Raku