willdo 0.0.1

Task manager with DAG
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84

# WillDo

Will do some work when the conditions are ripe!

It is a generic task manager for running jobs
with a directed acyclic graph (DAG) dependency resolution.
Configuration is loaded from simple yaml files:

```yaml
job: baking
script:
    - echo oven 250
    - echo insert yummy
    - sleep 3600
    - echo oven off
    - echo take yummy
---
job: oops
when:
    - done: baking
      code: 
        min: 1 # that is non-zero, baking failed
script: echo alarm!
---
job: cleanup
when:
    - any:
        - done: baking # assuming 0 - success
        - done: oops
script: echo tidy up
```

Jobs are effectively scheduled when their parent dependencies
(`when`) are satisfied. Dependencies can be conditional
with a simple code arithmetic conditions and combined
into complex rules (all/any). By default, all
dependencies must be satisfied. 

Triggers (`then`) are opposite - child - relations.

The crate includes a subprocess commander behind a feature of same name,
so any shell or repl can be utilized immediately to run your scripts.
The default commander is `()` which does nothing.

You can configure an interpretter:

```yaml
interpretter: sh
provider: subprocess
executable: dash
---
job: making
runs: sh
script:
    - test -f .skip && echo skipped || echo make
```


In order to discern the outcome of a script command,
the commander must provide feedback to send back
the numeric code of the last operation.
This is not easily done in a subprocess
and is achieved by printing a uniquely
stamped string that is parsed from child
process outputs.

# Usage

 1. Use it as a crate in your project - see examples and docs to get started.
    The `Graph` implements `Display` with a digraph output which can be rendered with graphviz
    to visualize the state. You can provide your own `Commander` to interpret job scripts.

 2. Build the examples that can run jobs as a CLI, you could install
    the examples with cargo, but I would not recommend it at this stage
    as the interfaces are not stable.

# TODO
- Pass resources between jobs, such as exit codes, outputs, variables.
- Preserve and load job state so we can pick up where we left off.
- An official and stable CLI.
- Later: other configuration sources.
- Later: fancy interactive TUI.
- Maybe: more ways to work with the graph.