* Add new build info metrics that contains more info
The goal was to add more information about Grafana. But rather than
just adding those to the current metrics I created a new metric
since its a common pattern in the prometheus community to expose that
info in a metric named `*_build_info`.
We keep the old metric to avoid introducing any breaking changes but
we should be able to remove it the next breaking change
- using grunt-newer to prefix precommit tasks
- only got it to work for tslint and tsc
Not applied to:
- sasslint does not take the file arguments in a way that grunt-newer
recognizes
- no-only-tests throws an error when used with `newer`, but it's
sub-second runtime
- when instantiating a datasource, the datasource service checks if the
plugin module exports Explore components, and if so, attaches them to
the datasource
- Explore component makes all major internal pluggable from a datasource
`exploreComponents` property
- Moved Prometheus query field to promehteus datasource and registered
it as an exported Explore component
- Added new Start page for Explore, also exported from the datasource
The grafana_stats.json used the following prometheus query: "increase(grafana_alerting_result_total[1m])" But a metric called "grafana_alerting_result_total" is currently not there anymore. So i changed the query to "increase(grafana_alerting_active_alerts[1m])" and updated the title as well (Before: "Grafana alert results", Now: "Grafana active alerts").
- added `node_modules` as new target
- dependency on `package.json` and `yarn.lock` allows for quick `make
node_modules` after a branch change, which noops when the deps have
not changed
- also added `clean` target
Implements rudimentary support for placeholder values inside a string
with the `PlaceholdersBuffer` class. The latter helps the newly added
sum aggregation query suggestion to automatically focus on the label
so users can easily choose from the available typeahead options.
Related: #13615
No label suggestions were being returned for multi-line aggregation
contexts because the parsed selector string does not see the full
context before a `by` or `without` clause.
This solution stitches together all text nodes that comprise the query
editor to ensure the selector has sufficient context to generate
suggestions.
Also, an additional workaround has been included to ensure range vector
syntax does not disrupt label suggestions in aggregation contexts.
Related: #12890
- use global range types
- add ErrorBoundary around individual Explore components
- fix table merge on empty results
- fix TimePicker date parsing on ISO dates
- fix TimePicker range string after relative move
