CI/CD automation on Grafana Labs

CI/CD pipeline architecture

Wed, 24 Jun 2026 15:16:44 +0200

CI/CD pipeline flow

This diagram shows the end-to-end pipeline from code commit to deployed dashboard.

What each stage does

The pipeline has three stages, each triggered at a different point in the workflow.

Stage	Trigger	Action
Generate	Every push	Run SDK code, produce dashboard JSON
Plan	Every push	Show what Terraform will change
Apply	Merge to main only	Deploy changes to Grafana

When each path runs

The same stages run along two paths, depending on where the code is in the workflow:

On a pull request: the pipeline runs generate and plan, then posts the plan as a PR comment for review. Nothing is deployed yet.
On merge to main: the pipeline runs all three stages. Generate produces the latest JSON and Terraform applies it, so the dashboard in Grafana always reflects the latest code on main.

The review gate

The Terraform plan output is posted as a PR comment so you can see:

Which dashboards will be created, updated, or destroyed
Exactly what configuration will change

This gives you the full benefits of dashboards as code: every change is reviewed, every deployment is automated, and you can trace any dashboard back to the commit that produced it.

GitHub Actions workflow

Wed, 24 Jun 2026 15:16:44 +0200

Complete workflow

You can deploy dashboards 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 dashboard lifecycle with GitHub Actions.

This workflow generates and deploys your dashboards. 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 generate and plan to preview the changes. On a push to main, it also runs apply to deploy them.

name: Deploy Grafana Dashboards

on:
  push:
    branches: [main]
  pull_request:

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

      - name: Set up Go
        uses: actions/setup-go@v5
        with:
          go-version: '1.24'

      - name: Generate dashboard JSON
        run: go run main.go

      - 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 generate-plan-apply pipeline.

Step	Purpose
Checkout	Access your repository code
Set up Go	Install the language runtime for SDK code
Generate JSON	Run your SDK code to produce dashboard files
Terraform Init	Download the Grafana provider
Plan/Apply	Preview or deploy dashboard 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 five steps. Your Foundation SDK code and Terraform configuration stay the same regardless of which CI tool runs them.

Secrets and variables

Wed, 24 Jun 2026 15:16:44 +0200

What you need

Your pipeline must authenticate to Grafana without exposing credentials in code. GitHub Actions provides two mechanisms: secrets for sensitive values and variables for non-sensitive configuration. You need three values: one secret and two variables.

Value	What it is	Type	Where to store
GRAFANA_TOKEN	Service account token that authenticates the pipeline to Grafana	Secret	Repository secrets
GRAFANA_SERVER	Your Grafana instance URL, for example `https://your-stack.grafana.net`	Variable	Repository variables
GRAFANA_STACK_ID	Your Grafana stack identifier	Variable	Repository variables

Add and reference your credentials

Store the three values in your repository, then reference them from your workflow.

In your repository, go to Settings > Secrets and variables > Actions.
On Repository secrets, add GRAFANA_TOKEN with your service account token. Never commit this token to your repository.
On Repository variables, add GRAFANA_SERVER and GRAFANA_STACK_ID.
Reference the secret with the secrets context and the variables with the vars context.

env:
  GRAFANA_SERVER: ${{ vars.GRAFANA_SERVER }}
  GRAFANA_STACK_ID: ${{ vars.GRAFANA_STACK_ID }}
  GRAFANA_TOKEN: ${{ secrets.GRAFANA_TOKEN }}

Authenticate Terraform

Pass authentication to the Terraform provider through environment variables or directly in the provider block. Set TF_VAR_grafana_url and TF_VAR_grafana_token as environment variables, and Terraform picks them up automatically. The environment variable approach keeps your Terraform code portable: the same configuration works locally and in CI.

provider "grafana" {
  url  = var.grafana_url
  auth = var.grafana_token
}

Reliable, repeatable deployments

Wed, 24 Jun 2026 15:16:44 +0200

How Terraform handles existing dashboards

A reliable pipeline produces the same result no matter how many times you run it, with no duplicate dashboards and no errors. Terraform ensures this with a state file: a record of the resources it has created. On each run, Terraform decides what to change by comparing three things:

Your configuration
The state file
What actually exists in Grafana

When the live dashboard no longer matches your code (for example, someone edited it in the UI), that difference is called drift. Because of this, you can safely retry failed runs and merge to main repeatedly without creating duplicates.

Scenario	What Terraform does
Dashboard doesn’t exist	Creates it and records in state
Dashboard exists and matches	No changes needed
Dashboard was edited manually	Detects drift, restores code-defined version

Why stable UIDs matter

A stable UID in your DashboardBuilder gives Terraform a consistent identifier to track across runs. With it, Terraform updates the same dashboard each time. Without it, Terraform has nothing to match against, so each deployment creates a new dashboard and you get duplicates on every run.

builder := dashboard.NewDashboardBuilder("My Dashboard").
  Uid("my-dashboard")  // Same UID = update, not duplicate