Graph

Terrabuild is based on DAG (Direct Acyclic Graph) where nodes are tasks to complete to reach a given goal.

This graph is based on projects and configurations of your workspace. Nodes of this graph have relationship with other nodes: they are the discovered or specified dependencies of the projects. Project configuration is specified using an HCL-like syntax.

Building this graph is important since this enables Terrabuild to perform important optimizations:

• do not build what has not changed
• use pre-built binaries
• narrow build scope

Sample workspace

Imagine following projects and dependencies as follow. Projects are managed individually, and each have a dedicated PROJECT.

flowchart LR
  classDef default stroke:black
  classDef root stroke-width:2px
  classDef publish fill:skyblue
  classDef build fill:palegreen
  classDef batch fill:orange

  publishA("publish A\n@dotnet publish\n@docker build\n@docker push") --> buildA("build A\n@dotnet build")
  buildA --> buildC("build C\n@dotnet build")
  buildA --> buildD("build D\n@dotnet build")

  publishB("publish B\n@docker build\n@docker push") --> buildB("build B\n@npm build")

  class publishA,publishB root
  class publishA,publishB publish
  class buildA,buildB,buildC,buildD build

Caching

If a project does not need to be rebuilt, build artifacts are restored and dependents can be built in turn.

Even better: if a branch of the graph does not lead to new artifacts, it can be safely ignored in CI context (this is usually not the case locally where developers needs artifacts).

For eg: if project A, C and D do not change, Terrabuild won’t even bother restoring artifacts since no artifacts are generated in CI.