<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> ### Problem to solve Currently custom metrics are stored in the database, and defined in project settings. This is less than ideal for a few reasons: * Changes are not version controlled * Changes are restricted to project administrators * No review process * and more. ### Target audience <!--- For whom are we doing this? Include a [persona](https://design.gitlab.com/research/personas) listed below, if applicable, along with its [label](https://gitlab.com/groups/gitlab-org/-/labels?utf8=%E2%9C%93&subscribed=&search=persona%3A), or define a specific company role, e.g. "Release Manager". Existing personas are: (copy relevant personas out of this comment, and delete any persona that does not apply) - Parker, Product Manager, https://design.gitlab.com/research/personas#persona-parker - Delaney, Development Team Lead, https://design.gitlab.com/research/personas#persona-delaney - Sasha, Software Developer, https://design.gitlab.com/research/personas#persona-sasha - Devon, DevOps Engineer, https://design.gitlab.com/research/personas#persona-devon - Sidney, Systems Administrator, https://design.gitlab.com/research/personas#persona-sidney - Sam, Security Analyst, https://design.gitlab.com/research/personas#persona-sam --> ### Further details <!--- Include use cases, benefits, and/or goals (contributes to our vision?) --> ### Proposal Instead of defining this data in project settings, the canonical dashboard configuration should be persisted in the repository. This would allow: * Changes to be version controlled and reverted * Dashboard changes can be reviewed, suggested, and discussed in an MR along with other such changes * Adding/removing/changing exported metrics should be done as part of changes to the dashboard representation as well * Follow other patterns of GitLab This could be relatively easy to do: * We know the branch an environment is based off * We then select that branch's configuration to use * Any changes to the dashboard can be committed back that branch, or offer to create another branch #### Risks * We should make sure adhoc dashboards, for example troubleshooting an incident, are easy to create and low friction ### What does success look like, and how can we measure that? <!--- Define both the success metrics and acceptance criteria. Note thet success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this --> ### Links / references