Slide 3 of 8

GitHub Actions workflow

Complete workflow

You can deploy resources with a single terraform apply. But if someone still has to remember to run that command after every change, you haven’t removed the human bottleneck. Now you’ll automate the full resource lifecycle with GitHub Actions.

This workflow plans and deploys your Grafana resources. It runs in two cases: when you open or update a pull request, and when commits are pushed to main. On a pull request, it runs plan to preview the changes. On a push to main, it also runs apply to deploy them.

YAML 
name: Deploy Grafana Resources

on:
  push:
    branches: [main]
  pull_request:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

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

      - name: Terraform Init
        run: terraform init

      - name: Terraform Plan
        run: terraform plan -input=false -no-color

      - name: Terraform Apply
        if: github.ref == 'refs/heads/main'
        run: terraform apply -auto-approve
        env:
          GRAFANA_AUTH: ${{ secrets.GRAFANA_TOKEN }}

Step breakdown

Each step in the workflow handles one stage of the plan-apply pipeline.

StepPurpose
CheckoutAccess your repository code
Setup TerraformInstall the Terraform CLI
Terraform InitDownload the Grafana provider
Plan/ApplyPreview or deploy resource changes

The if: github.ref == 'refs/heads/main' condition on the apply step gates deployment: plan runs on every push, but apply runs only when changes land on main. Pull requests get a plan preview without deploying anything.

Alternative CI systems

You can adapt this to other CI systems (GitLab CI, CircleCI, Jenkins) by translating the same four steps. Your Terraform configuration stays the same regardless of which CI tool runs it.

Script

Here’s a complete GitHub Actions workflow that plans and deploys Grafana resources. It runs whenever you push commits to main or open a pull request.

The workflow has four key steps. First, it checks out your repository. Second, it sets up Terraform. Third, it initializes Terraform and runs terraform plan to preview changes. Finally, on pushes to main, it runs terraform apply to deploy.

The conditional logic is straightforward: plan runs on every push, but apply only runs when changes land on main. This means pull requests get a plan preview without deploying anything.

Because there’s no generate step, this workflow is simpler than the dashboards-as-code pipeline. Your HCL files are your source of truth, and Terraform handles the rest.

You can adapt this to other CI systems (GitLab CI, CircleCI, Jenkins) by translating the same four steps. Your Terraform configuration stays the same regardless of which CI tool runs it.

Previous Next