grafana/grizzly

[Feature Request]: Supporting the Folder Structure in `grr serve`

mehmetozturk4705 opened this issue · 2 comments

mehmetozturk4705 commented

Feature Request

Hello,

We really liked your contributions lately, which makes it easier managing resources under Grafana!

We have tried the newly introduced serve command which builds easier saving flow for the local development. One point I noticed is, currently the saving over serve strips out the folder data.

User Story

As a grafana developer, I would like the target folder structure to be kept. So I can pull an existing Dashboard, work with serve on local, and then apply it without changing the folder structure.

Workarounds

There were several workarounds that did not resolve the behavior as I expected as below:

  • I pulled also the existing folders into VCS, kept the local folder structure as Dashboards/<folder-uuid>/dashboard-name.yaml and then save through the serve proxy.
  • I tried to setup folder through local proxy UI, and that also failed to fetch the folders even if there were folders also under the serving source.

We actually did not want to post-process output yaml's since we mainly use python and it might differ in terms of yaml implementation with Go. (multiline strings, escapes etc.)

malcolmholmes commented

Thanks for this - a valuable observation. It should be fixed by #427 (which depends upon #386 being merged, hopefully this week).

I'm glad you are finding this serve functionality useful - I'd very much appreciate hearing any further feedback you might have about its use (even if just "it works fine!" :-) ). Please feel free to use discussions for this.

And thanks again!

mehmetozturk4705 commented

Thanks for this - a valuable observation. It should be fixed by #427 (which depends upon #386 being merged, hopefully this week).

I'm glad you are finding this serve functionality useful - I'd very much appreciate hearing any further feedback you might have about its use (even if just "it works fine!" :-) ). Please feel free to use discussions for this.

And thanks again!

I think it is valuable toolset for us generally.

We are also finding our way still while developing "dashboards as code" in terms of procedure. But even now it saved us by enabling us getting rid of unneeded development dashboards, and create a nice QA for business critical dashboards.

We are actually planning to check out for better "diff"ing when in reviewing process, specificly for the SQL diffs. So I would love to share in a discussion topic then.