groupoptimizevision is to make GitLab the tool of choice for data-driven DevOps organizations. To achieve this one of our goals is to make Value Stream Analytics (VSA) the hub of analytics in GitLab, and customizable analytics dashboard is a core functionality in this direction.
The objective of this Spike Research is to determine the feasibility of enhancing insights.yml to be GitLab's customizable analytics dashboard.
Problem to solve
GitLab Analytics provide high value to executives. However, these reports are spread across multiple pages in GitLab and may require specific filters to be applied to be relevant. Executives' time is very valuable, and they might not know how to use GitLab to get insights that are relevant to their business.
JTBD: I want to create my own dashboards in GitLab that mirror the processes and terminology that my company is currently using.
Investigation and clarification questions:
What is the future of the insights YAML format?
Is there a new version?
Should we upgrade to the new version?
Will that cause breaking changes and disruption for current Insights users
What is the future of the insights YAML format?
Is there a new version? Should we upgrade to the new version? Will that cause breaking changes and disruption for current Insights users
The insights YAML file format was developed in-house, there is no new version. For introducing YAML "schema" changes should happen in a backwards-compatible manner.
Can insights.yml embed in:
VSA? Issues?
Do you mean a list of issues? There is no support for embedding lists. Lists are problematic due to pagination, probably something like top 10/20 issues would work.
Can we add custom drill-down link?
We can extend the YAML schema to support linking, assuming that the underlying charting library can handle links.
Can we add auto page refresh to load data every 15 minutes?
Currently, the insights feature uses real-time API calls so the data can be considered fresh on page load. I'd advise against adding an auto page refresh feature because it'd add unnecessary load to our backend (a user leaves the browser open).
Can we add counters tiles in Insights with near real-time measurements - data load every 15 minutes.
See my answer above.
Do you mean like total issue count? Should be doable, keep in mind that large COUNT() queries will be slow and can cause page load failures. See my related research: &7964
Can we configuration insights to allow for a collection of charts per page?
There is a grouping feature built into insights, users can define different pages with different chart configurations.
Do you mean switching from the Page dropdown to having a clickable ToC? Or do you mean adding more text, like a description for each page/chart?
Both, but also to gives users an overview of the page contents, how it organized and to allow the user to go directly to a specific report within the page.
Can we giving users the option to embed below the Tasks by type chart a customize insights.yml report?
The Task by Type chart shows the daily distribution of issues and MRs by the top 10 labels in the Group. If the user who configures the YML "knows" the top labels, then the Task by Type chart can be replicated in Insights.
Can we give users the option to replace the VSA overview tiles with embed customize insights.yml tiles?
It should be doable however, it requires careful planning:
Chart definition in insights
Extend the YML definition
Add a chart to a page
Where to place the chart?
Sizing, will the chart fit into the page?
CSS positioning issues
Persisting the charts. We need to store the chart positions somewhere.
Why not adding limitations to the API to avoid the slow queries?
We already have limits on the queries, if the query runs 15s, the backend will cancel the query. The page will show an error message (broken feature).
These metrics dimensions are requested by customers:
AFAIK insights don't support dimensioning: it can "emulated" to some extent by running insights from a specific group or subgroup. Dimension/grouping is a quite expensive operation on the DB level, I don't think it would be performant enough with the current DB setup.
Other than performance, is there a limit to the number of reports per page?
In VSA Overview stage, at the bottom of the page, add the insight page dropdown.
The VSA landing page already makes several API calls to load the VSA data (aggregated data). Adding more API calls, and more things to load can slow down the page considerably => increase the error budget
We already have a date range selector for VSA, a different date range and the lack of filtering for this chart might confuse the users.
Add a new insight page "DORA Metrics Tredns" with line chart for each DORA metrics.
The Insights feature is configured by the end-user in the project's git repository using a YAML file. One way to make this work without configuration is to build an Insights configuration structure in memory and call the Insights' data collector.
Breakdown:
Adapt the Insights YAML to support different query types (DORA). Weight: 8
Create an endpoint where we can request DORA insights data (4 DORA metrics). Weight: 4
The Insights feature can be extended to use different data sources for rendering the charts. Having a standard way to describe charts is a big win IMHO. This gives us the ability to add or embed charts to various GitLab pages.
Pros:
We already use a YAML-based schema. Extension in a backwards-compatible manner is possible.
The chart rendering is already there, if we don't want to introduce new chart types then UI work will be minimal. Only the backend needs to change.
Cons:
In-house built, non-standard. Users might find it difficult to configure the charts.
The feature may become very complex once we start adding more features, linking/drill-down, new chart types, and new data sources.
Within the codebase the parameter handling is implemented in the InsightsActions module which is mixed into the controller.
Idea:
Controller -> InsightsDataRequest -> Data -> Serializer
Move out query parameter related logic from the controller into the new InsightsDataRequest class. This class is responsible for validating the incoming query params and deciding which data source to invoke (and how to invoke it). The returned data is passed into the Serializer.
Pseudo code:
ifparams[:query][:data_source]=='dora'# validateDora::AggregateMetricsService...# serializeelsifparams[:query][:data_source]=='issuable'# validateGitlab::Insights::Finders::IssuableFinder...# call reducers# serializeelse# backward compatibility for the old YAML schema, call the issuable codeend
@ahegyi This issue looks like it may slip this current milestone. Can you leave a or to signify if you are on track to deliver this issue?
Please also consider updating the issue's Health Status or Milestone to reflect its current state,
and communicate with your Product Manager as appropriate.