VCS

Set Up

Connect a VCS repository if you haven't already. After selecting VCS as the source, set the following options:

• VCS Provider - Select the provider that contains the Terraform and OpenTofu repositories.

• Repository - Select the repository where the code resides.

• Branch - Select the branch that Scalr should trigger a run off of when a PR is opened or merged.

• Terraform Working Directory - This is where Terraform actually runs. This directory must be a subdirectory of the top level of the repository or of the subdirectory if specified. This comes in handy in the case of a mono repo.

• Trigger Strategy - The rules in which a run should be triggered based on files or folders being updated.

  • Any Changes - Any change in the repository specified will trigger a run.
  • Trigger Patterns - Use glob patterns to specify which files/directories should initiate a run. Patterns can be used in combination with a working directory, but not with trigger prefixes. For example, if the following patterns were set a run would execute if there were changes inmy/awesome/workdir/ or modules/core/iam/teams, but changes to any .md files would be ignored.

  my/awesome/workdir/
  modules/core/iam/teams
  !*.md
  

  • Directories - Use a working directory as well as trigger prefixes to trigger a run based on any files being changed in any of the directory paths. Trigger prefixes cannot be used in combination with trigger patterns.

• Enable VCS-driven dry runs - This is a control mechanism to avoid unwanted dry runs on every commit.

• Clone submodules - This allows you to specify whether git submodules should be fetched when cloning a VCS repository.

• Select variable files - This specified which tfvar files should be pulled in from the repository.

• Skipping specific commits - If you would prefer that a run is not started based on a VCS commit or PR, add [skip ci] in the first line of a head commit message. Users will still be able to queue runs manually if the configuration version is associated with a commit with the skip tag. Use [skip scalr ci] to avoid conflict with other CI tools that use the same message.

Pull Requests

Scalr will execute a dry run (plan-only) upon creating a pull request against the branch the workspace is linked to if the working directory or trigger pattern are affected. Subsequent commits to the pull request will also trigger a dry run regardless of the code changed in the new commit. Scalr evaluates all commits in the pull request on every new push, not just the latest commit.

Execute a Run from a Pull Request Comment

For VCS-based workspaces, a plan or apply run can be executed directly from pull request comment. As of right now, only Github is supported, but other VCS providers will be added soon. To execute a run from a comment simply execute the following in a pull request comment:

/scalr plan

or

/scalr apply

The status of the run will be sent back to the VCS provider as a comment:

If the workspace setting "Enabled VCS-driven dry runs" is disabled, the /scalr plan command will not work, but apply will. To override this, use the -force flag to force a plan to execute: /scalr plan -force

Command List:

The ability to execute runs from a comment is controlled through the [VCS provider settings](https://docs.scalr.io/docs/github).

Provider Configurations

Before executing a run in a workspace, credentials must be added so that the code can authenticate to the Terraform provider during the run. This can be done through the Scalr provider configuration feature. Provider configurations give users a central place to manage their configurations and assign them for use within environments and workspaces.

Set Variables

Once the workspace is saved, variables might need to be added to the workspace if required. Find out more about setting shell and Terraform/Tofu variables here.

Execution

A run will execute upon the next commit, pull request, or manual execution of a run. Alternatively, you can set auto-queue run to always, which will automatically start a run upon the workspace being created. Auto queuing of runs is helpful when you automatically create workspaces through the Scalr provider as you can kick off a run in the workspace as soon as it is provisioned via Terraform without manual intervention.

Runs can also be triggered based on users adding a /scalr plan comment to the comments of a pull request.

Extra Settings

There are other optional settings that can be applied to all workspace types which can be found in workspace settings.