Tasks
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.
For that, 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 also tracks the build timestamp of each dependency. If a dependency has been rebuilt (its artifact is newer than the target), Terrabuild triggers a rebuild of the target, since most build systems are not idempotent and may produce side effects.
terrabuild.head_commit or terrabuild.branch_or_tag variables), this key is unique across branches. This is a really major concept since this enables important build optimizations.Once the key has been computed, Terrabuild uses the target configuration and following decision tree to decide what to do:
flowchart LR
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
start((" "))
force(Force ?)
cache(In cache ?)
dependency(Dependency rebuilt ?)
retry(Retry ?)
failed(Failed ?)
restore((Restore))
build((Build))
start --> force
force -- yes --> build
force -- no --> cache
cache -- yes --> dependency
cache -- no --> build
dependency -- yes --> build
dependency -- no --> retry
retry -- no --> restore
retry -- yes --> failed
failed -- no --> restore
failed -- yes --> build
class start start
class build build
class restore restore
class force,cache,dependency,retry,failed decision| Condition | Description |
|---|---|
Force | either --force or rebuild (target) enabled |
In cache | target is available in cache |
Dependency rebuilt | a non-idempotent dependency has been rebuilt for some reasons |
Retry | --retry enabled |
Failed | previous build has failed |
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 further executions.