Resourcely Documentation
LoginSign Up
  • Get Started
    • 🎱What is Resourcely?
    • 👋Why Resourcely
    • 🏃Quickstart
      • Terraform policies integrated into CI
      • Remediate policy violations in existing infrastructure
      • Templates for generating Terraform
      • Glossary
  • Concepts
    • Foundry
      • Create Blueprints with Foundry
      • Creating Guardrails with Foundry
      • lmport Terraform Modules
    • Guardrails
      • Writing your own Guardrails
      • Editing Guardrails
      • Releasing Guardrails
      • Enabling Inactive Guardrails
      • Guardrails in Action
        • 🐱GitHub Actions
        • 🦊GitLab Pipelines
    • Campaigns
      • Get started with Campaigns
      • Creating Campaigns
      • Remediate Resources
      • Campaign Agent
        • State File Support
          • Amazon Simple Storage Service (S3)
          • Google Cloud Storage (GCS)
          • HCP Terraform
          • Spacelift
        • Running Campaigns with GitHub Actions and a Repo-Hosted State File
        • Running Campaigns Locally
    • Blueprints
      • Authoring Your Own Blueprints
      • Using Built-in Resourcely Blueprints
      • Configuring Global Contexts
      • Deep Linking
    • Resources
      • Provisioning Infrastructure
      • Editing Infrastructure
      • Shopping Cart
      • Config Roots and Environments
    • Other Features and Settings
      • Global Values
      • Global Context
      • Metrics
      • Resourcely-cli
      • Resourcely.yaml
      • VCS Proxy
      • Settings
        • User management
        • Company Information
        • Notification Settings
        • Change Management
          • 🐱Connect to GitHub
          • 🦊Connect to Gitlab
        • Generate API Token
    • ✨Production Setup
      • Single Sign-On (SSO)
        • Auth0
        • AWS Single Sign-On
        • Azure AD
        • Google Workspace
        • JumpCloud
        • Okta
        • Omnissa Workspace ONE (formerly VMware)
        • OneLogin
        • Ping Identity
        • Other SAML / OIDC Providers
      • Source Code Management
        • Page
        • 🐱GitHub
        • 🦊GitLab
        • Atlassian Bitbucket
        • Azure Repos
  • Tutorials and guides
    • Remediation Use Cases
      • Apply tags to resources for automating backups
      • Implement centralized logging
    • Blueprints Use Cases
      • Automate Data Pipeline Creation
      • Encryption for GCP
      • AWS Account Factory
      • Streamline and govern AI
      • IAM Factory
      • Cost optimization for FinOps
      • Guardrails for Terraform Modules
    • Using the Resourcely Terraform Provider
      • Setup Resourcely Provider
      • Blueprints
      • Guardrails
      • Global Context
  • Integrate
    • CI/CD & Terraform Runners
      • Atlantis
      • 🐟AWS CodeBuild
      • Azure Pipelines
      • Buildkite
      • CircleCI
      • CloudBees CI
      • Codefresh
      • Digger
      • Env0
      • 🎏GitHub Actions
        • 🐱Local Plan
          • 🐹AWS with OpenID Connect
        • 🐶Terraform Cloud Integration
      • 🦊GitLab Pipelines
      • Harness
      • 🗻HashiCorp Cloud Platform (formerly Terraform Cloud)
      • Jenkins
      • Octopus Deploy
      • Scalr
      • 🌌Spacelift
      • Terramate
      • 🌎Terrateam
    • Cloud Providers
      • 🌨️Amazon Web Services (AWS)
      • 🤓Google Cloud Platform (GCP)
        • Guardrail Gaunlet at Google Cloud Next 2025
      • 💾Microsoft Azure
      • Alibaba Cloud
      • Huawei Cloud
      • IBM Cloud
      • Oracle Cloud Infrastructure (OCI)
      • Tencent Cloud
      • VMware vSphere
    • Developer Portals
      • Atlassian Compass
      • Backstage
      • Cortex
      • Harness IDP
      • Home grown internal developer portals
      • OpsLevel
      • Port
      • Roadie
    • ITSM
      • Atlassian Jira
      • FreshWorks
      • ServiceNow ITSM
      • ZenDesk
    • CSPM
      • Wiz
    • More Terraform Provider Integrations
      • 🚂ConductorOne Provider
      • Databricks Provider
      • Kubernetes Provider
      • 🐕Datadog Provider
      • ❄️Snowflake Provider
Powered by GitBook
On this page
  • Adding Required Variables to the Repository
  • Github Actions as Terraform Runner
  • Resourcely Github Actions Scaffolding
  • Github Actions with multiple config roots
  1. Integrate
  2. CI/CD & Terraform Runners
  3. GitHub Actions

Local Plan

CI/CD Automation

PreviousGitHub ActionsNextAWS with OpenID Connect

Last updated 4 months ago

This integration requires that the Terraform plan file be available to GitHub Actions and visible to the Resourcely. You must perform the following steps:

  • Adding Required Variables to the Repository

  • Configure GitHub Actions as a Terraform Runner

Adding Required Variables to the Repository

Resourcely can be configured using environment variables. Some variables are optional and used for configuration, while others must be defined before the guardrails can be validated.

Key
Description
Secret

RESOURCELY_API_TOKEN

(Required) Token generated from the Resourcely portal. Used to verify infrastructure guardrails.

Yes

TF_PLAN_DIRECTORY

(Optional) The directory where the terraform files to verify are located.

Default Value: tf-plan-files

No

TF_PLAN_PATTERN

(Optional) Pattern for Terraform plan files (e.g., plan*).

Default Value: plan*

No

Secret variables allow you to store sensitive information in your organization, repository, or repository environments.

  1. Open the repository you want Resourcely to watch

  2. Click the Settings tab

  3. Under the Security section, expand Secrets and variables, then select Actions.

  4. Under the Repository secrets section, press the New repository secret button

  5. Add the following variables and their values one at a time and press the Add secret button

You can learn more about GitHub Secret variables by checking out the following documentation:

Github Actions as Terraform Runner

Now let's add the Resourcely job to GitHub Actions in order to perform the following actions:

  • Obtain the resourcely-cli Docker container, which is used to download policies from Resourcely, assess them, and submit the results to Resourcely. As a result, these findings will be displayed on your GitHub pull requests each time a new pull request is submitted.

  1. Open the repository you want Resourcely to watch

  2. Create a file named terraform.yml under .github/workflows. If the directory does not exist, create it.

  3. Copy and paste the following code and make configuration changes as needed

name: Plan and Apply Terraform

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  terraform:
    name: 'Terraform'
    runs-on: ubuntu-latest
    environment: production

    defaults:
      run:
        shell: bash

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v1

      - name: Terraform Init
        run: terraform init

      - name: Terraform Plan
        run: terraform plan -out=plan.raw

      - name: Convert the plan to JSON
        id: planToJson
        run: terraform show -json plan.raw

      - name: Save JSON to a file
        uses: fishcharlie/CmdToFile@v1.0.0
        with:
          data: ${{ steps.planToJson.outputs.stdout }}
          output: plan.json

      - name: Upload Terraform Plan Output
        uses: actions/upload-artifact@v4
        with:
          name: plan-file
          path: plan.json

  resourcely-ci:
    needs: terraform
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Download Terraform Plan Output
        uses: actions/download-artifact@v4
        with:
          name: plan-file
          path: tf-plan-files/

      - name: Resourcely CI
        uses: Resourcely-Inc/resourcely-action@v1
        with:
          resourcely_api_token: ${{ secrets.RESOURCELY_API_TOKEN }}
          resourcely_api_host: "https://api.resourcely.io"
          tf_plan_directory: "tf-plan-files"
  1. Commit the change to the main branch

You should now have the Resourcely Action enabled in GitHub, which will run each time a new resource generation PR is created.

Resourcely Github Actions Scaffolding

Github Actions with multiple config roots

If you have multiple config roots, you'll likely want them to run in the same action. Update the existing workflow to specify each config root directory name in the strategy.matrix. And set the working directory for the job to use this value.

jobs:
  terraform:
    name: 'Terraform'
    runs-on: ubuntu-latest
    environment: production

    strategy:
      matrix:
        config_root: ["<<config-root-folder1>>", "<<config-root-folder2>>"]

    defaults:
      run:
        shell: bash
        working-directory: ${{matrix.config_root}}

Additionally, update the upload step so that each plan gets a unique name

 - name: Upload Terraform Plan Output
        uses: actions/upload-artifact@v4
        with:
-          name: plan-file 
+          name: plan-file-${{matrix.config_root}}
          path: plan.json

Then include a download step for each config-root to the resourcely-ci job

      - name: Download Terraform Plan Output
        uses: actions/download-artifact@v4
        with:
          name: plan-file-<<config-root-folder1>>
          path: tf-plan-files/
          path: tf-plan-files/plan-file-<<config-root-folder1>>
        with:
          # grab the resourcely api token stored in the repo secrets
          resourcely_api_token: ${{ secrets.RESOURCELY_API_TOKEN }}
          manifest: | 
            {
              "plans": [{
                "plan_file": "plan-file-<<config-root-folder1>>/plan.json",
                "config_root_path": "<<config-root-folder1>>"
              },{
                "plan_file": "plan-file-<<config-root-folder2>>/plan.json",
                "config_root_path": "<<config-root-folder2>>"
              }]
            }

Note: Theis imported from the GitHub Actions Marketplace

This helps to integrate Resourcely into repository that used Github Actions as the Terraform runner.

It contains a that waits for terraform plan and then uses the to evaluate guardrails on that plan.

Note: If you wish to use the GitHub Actions Scaffolding and plan to configure AWS credentials, we recommend the assume role approach with .

Lastly, supply a manifest of your config roots to the

🎏
🐱
Resourcely CI Action
repository
workflow
Resourcely Github Action
OpenID Connect
resourcely-action
LogoEncrypted secrets - GitHub DocsGitHub Docs
GitHub Secret Variable Documentation