Task Lifecycle
Terrabuild aims at scheduling tasks to complete goals (which are targets). For this, Terrabuild creates a graph with all automatically discovered projects, targets and project dependencies. For each tasks (which are nodes of this graph), Terrabuild has to decide what to do.
To decide what to do, Terrabuild relies on a cache (either local or remote). A cache is driven by a key: this key (which is the unique identifier of the task) is built using:
- hash of files of the project
- project dependencies
- variables used for task
terrabuild_head_commit
variable), this key is unique across branches. This is a really major concept since this enables important optimization.Once the key has been computed, Terrabuild applies following decision tree to discover what to do with this task:
flowchart TB classDef start fill:black classDef build stroke-width:4px,stroke:black,fill:white classDef restore stroke-width:4px,stroke:black,fill:white classDef decision stroke:black classDef use-cache fill:#b0f1da,stroke:black,stroke-dasharray: 10 2,rx:10,ry:10 classDef dynamic fill:#CEB1FB,stroke:black,stroke-width:1px,stroke-dasharray: 5 2,rx:10,ry:10 start((" ")) force{{Force ?}} restore((Restore)) build((Build)) subgraph use-cache[ ] cacheable{{Cached ?}} younger{{Out of date ?}} retry{{Retry ?}} subgraph dynamic[ ] external{{External state ?}} state-changed{{External state out of date ?}} end end start --> force force -- yes --> build force -- no --> cacheable cacheable -- no --> build cacheable -- yes --> younger younger -- yes --> build younger -- no --> retry retry -- yes --> build retry -- no --> external external -- yes --> state-changed external -- no --> restore state-changed -- yes --> build state-changed -- no --> restore class start start class build build class restore restore class force,cacheable,younger,retry,ext,state-changed decision class use-cache use-cache class dynamic dynamic
Condition | Description |
---|---|
Force | either --force (global) or rebuild (target) |
Cached | all operations on target are cacheable and task has been previously built |
Out of date | previous build is younger than dependencies |
Retry | previous build has failed |
External state | some operations on target have an externally managed state |
External state out of date | external state is considered modified |
Decision is either Build
or Restore
leading to a new state for the task. Note that if task is built (or built again), this triggers in turn build of dependent nodes.
In all cases, new state is stored in local cache. If connected to a backend, task state is uploaded and can be used in next executions.