Data Source scalr_workspace

Retrieves the details of a single workspace.

Example Usage

data "scalr_workspace" "example" {
  id             = "ws-xxxxxxx"
  environment_id = "env-xxxxxxx"
data "scalr_workspace" "example" {
  name           = "my-workspace-name"
  environment_id = "env-xxxxxxx"

Argument Reference

The following arguments are supported:

  • id - (Optional) ID of the workspace.
  • name - (Optional) Name of the workspace.
  • environment_id - (Required) ID of the environment, in the format env-<RANDOM STRING>.

Arguments id and name are both optional, specify at least one of them to obtain scalr_workspace.

Attribute Reference

All arguments plus:

  • auto_apply - Boolean indicates if terraform apply will be automatically run when terraform plan ends without error.

  • force_latest_run - Boolean indicates if latest new run will be automatically raised in priority.

  • operations - Boolean indicates if the workspace is being used for remote execution.

  • execution_mode - Execution mode of the workspace.

  • terraform_version - The version of Terraform used for this workspace.

  • working_directory - A relative path that Terraform will execute within.

  • run_operation_timeout - The number of minutes run operation can be executed before termination.

  • module_version_id - The identifier of a module version in the format modver-<RANDOM STRING>.

  • tag_ids - List of tag IDs associated with the workspace.

  • vcs_provider_id - The identifier of a VCS provider in the format vcs-<RANDOM STRING>.

  • vcs_repo - If a workspace is linked to a VCS repository this block shows the details, otherwise {}

  • created_by - Details of the user that created the workspace.

  • has_resources - The presence of active terraform resources in the current state version.

  • deletion_protection_enabled - Boolean indicates whether to prevent deletion when the workspace has resources.

  • auto_queue_runs - Indicates if runs have to be queued automatically when a new configuration version is uploaded.

    Supported values are skip_first, always, never:

    • skip_first - after the very first configuration version is uploaded into the workspace the run will not be triggered. But the following configurations will do. This is the default behavior.
    • always - runs will be triggered automatically on every upload of the configuration version.
    • never - configuration versions are uploaded into the workspace, but runs will not be triggered.
  • hooks - List of custom hooks in a workspace.

    The hooks block supports:

    • pre_init - Script or action configured to call before init phase
    • pre_plan - Script or action configured to call before plan phase
    • post_plan - Script or action configured to call after plan phase
    • pre_apply - Script or action configured to call before apply phase
    • post_apply - Script or action configured to call after apply phase

The vcs_repo block contains:

  • identifier - * The reference to the VCS repository in the format :org/:repo, this refers to the organization and repository in your VCS provider.
  • path - Path within the repo, if any.
  • dry_runs_enabled - Boolean indicates the VCS-driven dry runs should run when the pull request to the configuration versions branch is created.
  • ingress_submodules - Designates whether to clone git submodules of the VCS repository.

The created_by block contains:

  • username - Username of creator.
  • email - Email address of creator.
  • full_name - Full name of creator.