publish dashboards as separate artifact

[rustyrazorblade]

Publish separately via GitHub actions as a standalone artifact so they can be used in other projects.

[rustyrazorblade]

@claude

[claude]

Claude finished @rustyrazorblade's task in 2m 34s —— View job

---

Publishing Dashboards as Separate Artifact

• Gather context and understand the request
• Explore existing dashboard files and GitHub Actions workflows
• Design GitHub Actions workflow for publishing dashboards

Note: I'm unable to push changes to .github/workflows/ files due to GitHub App permission restrictions (requires the workflows scope). Please create the following file manually:

---

File to create: .github/workflows/publish-dashboards.yml

name: Publish Dashboards

on:
  push:
    tags:
      - 'v*'

permissions:
  contents: write

jobs:
  publish-dashboards:
    name: Package and publish Grafana dashboards
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v6

      - name: Package dashboards
        run: |
          DASHBOARDS_DIR="src/main/resources/com/rustyrazorblade/easydblab/configuration/grafana/dashboards"
          mkdir -p artifacts

          cd "$DASHBOARDS_DIR"
          zip -j "$GITHUB_WORKSPACE/artifacts/easy-db-lab-dashboards.zip" *.json
          cd "$GITHUB_WORKSPACE"

          echo "Dashboard archive contents:"
          unzip -l artifacts/easy-db-lab-dashboards.zip

      - name: Upload dashboards to release
        uses: softprops/action-gh-release@v2
        with:
          files: artifacts/easy-db-lab-dashboards.zip

How it works:

• Triggers when a version tag (e.g., v1.2.3) is pushed
• Packages all 11 dashboard JSON files from src/main/resources/com/rustyrazorblade/easydblab/configuration/grafana/dashboards/ into easy-db-lab-dashboards.zip
• Uploads the zip as an asset to the GitHub Release for that tag using softprops/action-gh-release (already used in the nightly build workflow)

Note on template variables: The dashboard JSON files contain __KEY__ template placeholders (e.g., __CONTROL_NODE_IP__, __BUCKET_NAME__) that are substituted at deploy time by the TemplateService. The published artifact will contain these raw templates. Other projects consuming these dashboards will need to handle the substitution themselves.

I'm unable to [create or update workflow files] due to GitHub App permission restrictions. You can find more information and potential workarounds in the FAQ.

[rustyrazorblade]

@claude Create this as a branch and send a PR

[rustyrazorblade]

@claude this should have had a proposal

[claude]

Claude finished @rustyrazorblade's task in 2m 21s —— View job • claude/issue-527-20260313-1428 • Create PR ➔

---

OpenSpec Proposal: Publish Dashboards as Standalone Artifact

• Create OpenSpec change directory and .openspec.yaml
• Write proposal.md — why, what changes, capabilities, impact
• Write design.md — context, goals/non-goals, decisions, risks
• Write tasks.md — implementation task checklist
• Commit and push

Created openspec/changes/2026-03-13-publish-dashboards-artifact/ with three artifacts:

proposal.md — The dashboards are purpose-built for database performance testing but currently only accessible inside the JAR. The proposal adds a GitHub Actions workflow to package all 11 dashboard JSON files into easy-db-lab-dashboards.zip and upload it as a release asset on every v* tag push.

design.md — Key decisions: trigger on version tags only (not nightly), single zip archive (not individual files), no template variable substitution in the published artifact (consumers must handle __KEY__ placeholders), workflow placed in .github/workflows/publish-dashboards.yml using softprops/action-gh-release@v2 (already used in the nightly build workflow).

tasks.md — Two tasks: (1) create the workflow file, (2) add docs explaining the artifact and the template variable substitution requirement.

[rustyrazorblade]

Can the template variables be switched to something thats grafana native? If someone wants to use the dashboards, better to not have custom template stuff. @claude

[claude]

Claude finished @rustyrazorblade's task in 2m 14s —— View job

---

Dashboards Already Use Grafana-Native Variables

• Gather context and understand the request
• Explore dashboard files to identify template variable usage
• Check how TemplateService interacts with dashboards
• Assess feasibility of Grafana-native variables

---

The dashboards are already 100% Grafana-native — the previous comment was incorrect about them having __KEY__ custom template placeholders.

Here's what the dashboard JSON files actually use:

Grafana template variables (standard Grafana feature):

• type: "datasource" variable — lets users pick their Prometheus datasource from a dropdown
• type: "query" variables using label_values() — dynamically discover cluster names, datacenters, racks, and nodes from actual metric labels
• ${datasource} syntax referenced throughout all panels

Example from cassandra-overview.json:

{
  "type": "datasource",
  "name": "datasource",
  "query": "prometheus",
  "label": "Datasource"
},
{
  "type": "query",
  "name": "cluster",
  "query": "label_values(up{job=\"cassandra-maac\"}, cluster)",
  "label": "Cluster"
}

The __ occurrences in dashboard files are all Prometheus __name__ metric selectors (standard PromQL syntax) — not custom template variables.

Where TemplateService is called: GrafanaManifestBuilder.buildDashboardConfigMap() calls templateService.fromResource(...).substitute() on dashboard JSON, but since there are no __KEY__ placeholders in those files, the substitution is a no-op. The actual template substitution happens in datasource config and other K8s manifest resources.

Conclusion: The dashboards are already portable and self-contained. They can be published as standalone artifacts without any changes. The only coupling to the specific deployment is the default datasource name ("VictoriaMetrics") in the template variable definition — but Grafana lets users change this at runtime via the dropdown.

---

Ready to proceed with implementing the GitHub Actions workflow to publish dashboards on versioned releases. Should I create an OpenSpec proposal first, or go straight to implementation on this branch?
• claude/issue-527-20260313-1509

[rustyrazorblade]

@claude openspec propose

[claude]

Claude finished @rustyrazorblade's task in 3m 7s —— View job • claude/issue-527-20260313-1751 • Create PR ➔

---

OpenSpec Proposal: Publish Dashboards as Standalone Artifact

• Gather context on dashboards and existing workflows
• Create .openspec.yaml
• Create proposal.md
• Create design.md
• Create tasks.md
• Commit and push

Created openspec/changes/2026-03-13-publish-dashboards-artifact/ with:

proposal.md — The 11 Grafana dashboards are purpose-built for database performance testing but currently only accessible inside the JAR. They are fully Grafana-native (using type: "datasource" and type: "query" with label_values() — no custom placeholders). Publishing them as a standalone zip on every versioned release makes them consumable by any external Grafana instance.

design.md — Key decisions:

• Trigger on version tags (v*) only — ties dashboards to versioned releases, not nightly builds
• Single zip archive easy-db-lab-dashboards.zip — simpler to link to and consume than 11 individual assets
• No datasource substitution — dashboards use Grafana's built-in datasource picker; users select their datasource at runtime
• Use softprops/action-gh-release@v2 — already in use in the nightly build workflow
• Workflow file requires manual creation — GitHub App lacks the workflows scope

tasks.md — Two tasks:

1. Create .github/workflows/publish-dashboards.yml (workflow content included verbatim; must be created manually by a human due to GitHub App permission restrictions)
2. Add docs/reference/dashboards.md and update SUMMARY.md

• claude/issue-527-20260313-1751