I see very clearly how we can make a decent competitor to https://dagger.io based on this.
@GTrunSec
It could be a combination of:
- a
nix based DSL that improves the ergonomics of writing the against the job json schema - real black magic dependencies based on so called stringContext (local prototype in stock)
- removal of the hard coded
docker driver. a job is just that. a job. It looks for a runtime environment, suitable schedulers are:
- in the vain of the above, it can be considered a bug if a job does not spec it's resource requirements. fallbacks and defaults are ok. ideally a TUI / GUI would be able to run a probe on a pipeline to sample the resource requirements and then spec accordingly. scheduling with out asking for resources is a non-solvable challange for any scheduler under resource / budget constraints
- to make
whaterwheel embeddable into e.g. a local running CLI / TUI, we need a state-less mode, that doesn't depend on a db repository, but well, forgets everything upon exit, for the dagger.io imitation, that's actually pretty great already. Without UI.
I see very clearly how we can make a decent competitor to https://dagger.io based on this.
@GTrunSec
It could be a combination of:
nixbased DSL that improves the ergonomics of writing the against the job json schema - real black magic dependencies based on so calledstringContext(local prototype in stock)dockerdriver. a job is just that. a job. It looks for a runtime environment, suitable schedulers are:nsjailfor linux -- waaay faster than dockerwhaterwheelembeddable into e.g. a local running CLI / TUI, we need a state-less mode, that doesn't depend on a db repository, but well, forgets everything upon exit, for the dagger.io imitation, that's actually pretty great already. Without UI.