Skip to content

Have ability to declare that one source set has some form of mustRunAfter dependency on another sourceset

This is applicable when one source set relies on the infrastructure created by another source set. This does not mean that it will always force the one source set to applied. It just means that if S2 has dependency on S1 then all the tasks in S2 has a mustRunAfter dependency on the Apply|Destroy|OutputJson tasks of S1.

All of the other tasks can run in parallel. If the Init tasks of both source sets run in parallel, the locking mechanism from #105 (closed) will prevent an concurrent update of the plugin cache.

== Workspaces

It gets a bit more complex with workspaces. If S1 has workspaces W1 and W2, then S2 tasks must also run after S1W1 and S2W2.

If we start with

terraform {
  sourceSets {
    s1 {
    }
    s2 {
      mustRunAfter('s1')
    }
  }
}

Then it is easy to introduce the tfS2Apply.mustRunAfter('tfS1Apply') relationship. However, if we have a mutation of the DSL that ends up being the equivalent of

terraform {
  sourceSets {
    s1 {
    }
    s2 {
      mustRunAfter('s1')
    }
  }
}

terraform {
  sourceSets {
    s1 {
      workspaces 'w1', 'w2'
    }
  }
}

Then S1 must somehoe find out about those additional workspaces and add tfS2Apply.mustRunAfter('tfS1ApplyW1', 'tfS1ApplyW2'). This cannot be done with task types.

Edited by Schalk W. Cronjé
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information