Overview

Workspace dependencies allow you to create interconnected infrastructure workflows where one workspace's outputs can be consumed by another, and runs can be automatically triggered based on successful runs in upstream workspaces.

It is common practice to reference outputs from other workspaces so that a Terraform configuration can make use of resources that have been deployed in another workspace.

State Sharing & Run Triggers in an Environment

State Access

To share state and outputs between two workspaces, access to the state must be explicitly granted. Workspace owners have the option to limit which workspaces can access the outputs of their workspaces. The following sharing options can be applied:

• All workspaces in an environment
• No workspaces (only accessed by the current workspace)
• Some workspaces

When some workspace is selected, users will be prompted to select the workspaces with which the output can be shared:

For cross-environment sharing, see the cross-environment section below.

Sharing State

Once access is granted to the state, it can be pulled with the remote state datasource. The code snippet can be copied from the workspace where the state will be shared. When using the datasource, it will only read outputs, not the entire state file.

data "terraform_remote_state" "state-1" {  
  backend = "remote"

  config = {  
    hostname = "<host>"  
    organization = "\<env_id>"  
    workspaces = {  
      name = "<workspace name>"  
    }  
  }  
}

The code snippet is automatically created by clicking on "remote state snippet":

Once copied, the datasource should then be used in the workspace that needs access to the outputs of the source workspace.

Run Triggers

Run triggers are a way to build dependencies between workspaces. The use case for this is that you might have one or more upstream workspaces that need to automatically kick off a downstream workspace based on a successful run in the upstream workspace. To set a trigger, go to the downstream workspace and set the upstream workspace(s). Now, whenever the upstream workspace has a successful run, the downstream workspace will automatically start a run.

If more than one workspace is added as the upstream, a successful run in any upstream workspace will trigger the downstream workspace run. For example, if two upstream workspaces finish at the exact same time, then the downstream workspace will have two runs queued.

The permissions required for a user to set the triggers are

• Downstream workspace requires workspaces:update
• Upstream workspace requires workspaces:read

If the downstream workspace has auto-apply enabled, then the apply will automatically occur once the trigger happens. If not, it will wait for approval.

Cross-Environment State Sharing & Run Triggers

Cross-environment state sharing can be done by using the federated environment capability. Federated environment access in Scalr enables users to create dependencies, whether state sharing or run triggers, between workspaces across different environments. By granting controlled access between environments, federated environments streamline cross-environment workflows while maintaining appropriate security boundaries.

When access is granted between environments, the list of workspaces from the other environment will appear in the state sharing and run triggers list.

Federated Environments

To enable federated environments, navigate to Environment Settings and select "Federated Environments." Choose which environment you want to share state with by adding it to the access list. This will also allow that environment to create run triggers from your current environment.

Once enabled, the workspaces from your current environment will appear as run trigger options in the other environment's workspace.

State Sharing

After enabling federated environments, users must also grant access in the workspace settings to allow state sharing between workspaces. When granting this access, users will see the environment name displayed below each workspace name:

Once the state sharing is added, the same remote state datasource code snippet mentioned above can be used to share the state.

Run Triggers

After federated environments are enabled, users will see workspaces from the other environment appear in their run triggers list, with the environment name displayed below each workspace name: