Runs

A run is the result of executing the Terraform deployment in a workspace. There are two types of runs, runs that include an apply and runs that exclude an apply, referred to as a dry run. All runs for a given workspace will be displayed in the runs tab. For VCS-driven runs, a commit hash is provided, which can be clicked on to help users understand what changes were made to the code prior to the deployment for the entire history of the workspace. CLI runs will be noted as CLI driven with the username of the person who created the run. This serves as a good way to audit the changes that have gone on within a workspace:

Run Dashboards

The runs dashboard, which exists at the account, environment, and workspace scope, serves as a central dashboard for all runs across all workspaces. From this page, runs can be canceled in bulk or approved/discarded as needed. A use case for the bulk cancellation is to reprioritize runs (i.e. you have an emergency change going in that cannot wait on prior runs to finish).

Click through demo:

The permissions to view the runs page can be controlled through runs-queue:read in the IAM roles.

Run Output

The output of a plan can be displayed in two different ways, the standard console output or through the smart plan output referred to as a visual plan.

The visual plan is useful when you have hundreds or thousands of resources and you need to quickly filter on the action that is occurring in the plan:

Dry Runs

Scalr will automatically kick off dry runs when a PR is opened against a branch that is linked to a Scalr workspace or if a user runs terraform plan through the CLI. If it is a VCS-driven run, Scalr will report the checks back to your VCS provider.

The "main" check seen below is a cumulative check across all workspaces that are connected to this repo and the working directory (if applicable). This check can be used to create a branch policy against to ensure only successful dry runs are merged. There will only be a successful green check if all runs are successful.

📘

Note

VCS driven dry runs are optional and can be enabled or disabled in the workspace settings.

Prioritize Runs

During active development phases, runs will build up in the queue. It's much easier to select the run you want to actually execute rather than having to go through and delete other runs one by one, which is what the force run feature does. By forcing a run, Scalr will automatically discard all previous pending runs to ensure the selected run executes as fast as possible. Just click on the lightning bolt to select the run to execute.

Target Resources

The target option gives users the ability to focus the Terraform run on a specific resource or set of resources:

After target is checked, select one or more resources that the run will impact once executed.

Scheduling a Run

This is different than the Run Scheduler feature within the workspaces settings as this schedule is specific to a single run and set by clicking queue run:

The schedule is set based on your browser timezone. Here are something considerations when using it:

• The schedule does not change the run queue order for the workspace, runs are still queued in the order they were created.
• The time set for plan/apply should be thought of as the earliest possible time the run can execute. The run could execute later depending on existing runs in the workspace that are in queue or running.
• To avoid misuse of this feature or possible drift, only one scheduled run can be set per workspace.

Built-In Variables

The following shell variables are built into the runtime environment for use as needed:

• SCALR_RUN_ID - The ID of the current run.
• SCALR_HOSTNAME - The Scalr hostname.
• SCALR_TERRAFORM_OPERATION - The current Terraform operation (plan or apply).
• SCALR_TERRAFORM_EXIT_CODE - The exit code (0 or 1) of the previous operation (plan or apply) and only available in after hooks.

See the full documentation for variables here: Variables