CI/CD automation on Grafana Labs

CI/CD pipeline architecture

Tue, 11 Aug 2026 10:11:48 +0200

CI/CD pipeline flow

You can commit dashboard JSON by hand after every SDK change, but that still depends on someone remembering to regenerate and push. A CI/CD pipeline removes that bottleneck.

This diagram shows one end-to-end flow from code change to a live dashboard when Git Sync is already connected to the repository.

What each stage does

Stage	Trigger	Action
Generate	Every push and pull request	Run Foundation SDK code and produce dashboard JSON
JSON check / review	Pull request	Confirm the generated JSON is what the PR intends to merge (for example fail if committed files are out of date)
Git Sync	After merge to the synced branch	Grafana polls or receives a webhook and updates provisioned dashboards from Git

When each path runs

On a pull request: the pipeline regenerates JSON and gives reviewers a chance to inspect the file changes before merge. Nothing needs to talk to the Grafana API for that review gate.
On merge to main (or whichever branch Git Sync watches): the merged JSON is in the repository, and Git Sync brings Grafana in line with Git.

The Foundation SDK still only generates files. Git Sync remains the sync step you set up in Grafana.

GitHub Actions workflow

Tue, 11 Aug 2026 10:11:48 +0200

Example workflow

This example uses GitHub Actions to regenerate dashboard JSON whenever you open a pull request or push to main. On a pull request it fails if the JSON files in the repo do not match what the generator produces, so reviewers know the committed files are current. After merge, Git Sync (not this workflow) updates Grafana from the repository.

Adapt the generate command and output path to match your project. The pattern is what matters: generate in CI, review JSON on the PR, let Git Sync sync after merge.

name: Generate Grafana dashboards

on:
  push:
    branches: [main]
  pull_request:

jobs:
  generate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

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

      - name: Generate dashboard JSON
        run: go run ./cmd/generate

      - name: Check JSON is up to date
        if: github.event_name == 'pull_request'
        run: |
          git add -N dashboards || true
          git diff --exit-code -- dashboards

Step breakdown

Step	Purpose
Checkout	Access your repository code
Set up Go	Install the language runtime for your SDK code (use Node setup instead for TypeScript)
Generate JSON	Run your SDK program and write dashboard files into the synced path (here, `dashboards/`)
Check JSON is up to date	On pull requests, fail if generated output differs from what the branch commits

There is no Terraform apply step and no gcx push in this happy path. After merge, the JSON on the synced branch is what Git Sync reads.

Alternative CI systems

You can translate the same stages to GitLab CI, CircleCI, or Jenkins. Your Foundation SDK code stays the same; only the pipeline syntax changes.

Secrets and variables

Tue, 11 Aug 2026 10:11:48 +0200

What this pipeline needs

When you connected Git Sync, Grafana got credentials to read your Git repository (for example a personal access token or another auth method). The CI workflow only regenerates JSON and checks that the repo files match. It does not call the Grafana API to deploy.

For that generate-and-check pattern you often need no Grafana secret in GitHub Actions. GitHub provides GITHUB_TOKEN automatically for checkout and related steps.

Value	What it is	Usually required for generate-and-check?
GITHUB_TOKEN	Built-in token GitHub Actions uses for repository operations	Provided automatically
Grafana service account token	API credential for talking to Grafana directly	No for this happy path (Git Sync applies changes)
Language / registry secrets	Tokens for private modules or package registries	Only if your generate step needs them

When you would add Grafana credentials

Add a Grafana token to repository secrets only if your pipeline also talks to Grafana (for example a separate gcx or API step). That is outside this journey’s happy path. Keep secrets in Settings > Secrets and variables > Actions, and never commit tokens to the repository.

Keep Git Sync auth in Grafana

Do not move your Git Sync repository credentials into the Actions workflow unless you have a specific reason. Git Sync authentication stays in Grafana under Administration > General > Provisioning.

Reliable, repeatable updates

Tue, 11 Aug 2026 10:11:48 +0200

Same UID, same dashboard

A reliable pipeline produces the same result no matter how many times you regenerate and merge. For Git Sync, that depends on a stable dashboard UID in your Foundation SDK code.

When Git Sync pulls dashboard JSON, Grafana overwrites an existing dashboard that has the same uid. If the UID changes every run, you risk creating additional dashboards instead of updating one.

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

What to expect after merge

Situation	What happens
Same UID, updated JSON in the synced path	Git Sync updates the existing dashboard (Grafana overwrites the dashboard with that `uid`)
New UID in the synced path	A new provisioned dashboard appears for that file

Why the review gate still matters

CI that checks generated JSON on the pull request keeps the committed files honest. Reviewers see the JSON diff before merge. After merge, Git Sync applies what is in Git, so the reviewed files are what Grafana receives.