* Add notification policies preview in alert rule form
Co-authored-by: Konrad Lalik <konrad.lalik@grafana.com>
* Refactor using new useGetPotentialInstances hook and apply some style changes
* Add notification policy detail modal
* Use backtesting api for simulating potential alert instances
* Fix logic to travserse all the children from the root route
* Split notification preview by alert manager
* Add instance count to matching policy header and fix some styles
* Move some logic to a new hook useGetAlertManagersSourceNames to make the code more clean
* Fix some tests
* Add initial test for NotificationPreview
* Use button to preview potential instances
* Add link to contact point details
* Add route matching result details
* Show AlertManager image in the routing preview list
* Add tests setup, add single AM preview test
* Handle no matchers and no labels use case
* Update some style in collapse component and fix policy path in modal
* Update modal styles
* Update styles
* Update collapse header styling
* Normalize tree nodes should happen before findMatchingRoutes call
* Fix findMatchingRoutes and findMatchingAlertGroups methods after reabasing
* Move instances matching to the web worker code
* Fix config fetching for vanilla prometheus AMs
* Add tests
* Add tests mocks
* Fix tests after adding web worker
* Display matching labels for each matching alert instance
* Add minor css improvements
* Revert changes added in Collapse component as we don't use it anymore
* Move the route details modal to a separate file
* Move NotificationRoute and preview hook into separate files
* Fix Alertmanager preview tests
* Fix tests
* Move matcher code to a separate file, improve matcher mock
* Add permissions control for contact point edit view link
* Fix from and to for the temporal use of backtesting api
* Fix tests, add lazy loading of the preview component
Co-authored-by: Sonia Aguilar <soniaaguilarpeiron@gmail.com>
* Fix preview test
* Add onclick on the header div so it collapse and expands when clicking on it, and update styles to be consistent with the rest of tables
* Adapt the code to the new rule testing endpoint definition
* Fix tests
* small changes after reviewing the final code
* compute entire inherited tree before computing the routes map
* Throw error in case of not having receiver in routesByIdMap and add test for the use case of inheriting receiver from parent to check UI throws no errors
* Add list of labels in the policy route path that produces the policy matchers to match potential instances
* Use color determined by the key, in label tags when hovering matchers in the policy tree
* Remove labels in modal and handle empty string as receiver to inherit from parent as we do with undefined
* Revert "Add list of labels in the policy route path that produces the policy matchers to match potential instances"
This reverts commit
|
||
---|---|---|
.. | ||
grafana-data | ||
grafana-e2e | ||
grafana-e2e-selectors | ||
grafana-eslint-rules | ||
grafana-runtime | ||
grafana-schema | ||
grafana-toolkit | ||
grafana-ui | ||
README.md |
Grafana frontend packages
This document contains information about Grafana frontend package versioning and releases.
Versioning
We use Lerna for packages versioning and releases.
All packages are versioned according to the current Grafana version:
- Grafana v6.3.0-alpha1 -> @grafana/* packages @ 6.3.0-alpha.1
- Grafana v6.2.5 -> @grafana/* packages @ 6.2.5
- Grafana - main branch version (based on package.json, i.e. 6.4.0-pre) -> @grafana/* packages @ 6.4.0-pre- (see details below about packages publishing channels)
Please note that @grafana/toolkit, @grafana/ui, @grafana/data, and @grafana/runtime packages are considered ALPHA even though they are not released as alpha versions.
Stable releases
Even though packages are released under a stable version, they are considered ALPHA until further notice!
Stable releases are published under the latest
tag on npm. If there was alpha/beta version released previously, the next
tag is updated to stable version.
Alpha and beta releases
Alpha and beta releases are published under the next
tag on npm.
Automatic prereleases
Every commit to main that has changes within the packages
directory is a subject of npm packages release. ALL packages must be released under version from lerna.json file with the drone build number added to it:
<lerna.json version>-<DRONE_BUILD_NUMBER>
Manual release
All of the steps below must be performed on a release branch, according to Grafana Release Guide.
You must be logged in to NPM as part of Grafana NPM org before attempting to publish to the npm registery.
-
Run
yarn packages:clean
script from the root directory. This will delete any previous builds of the packages. -
Run
yarn packages:prepare
script from the root directory. This performs tests on the packages and prompts for the version of the packages. The version should be the same as the one being released.- Make sure you use semver convention. So, place a dot between prerelease id and prerelease number, i.e. 6.3.0-alpha.1
- Make sure you confirm the version bump when prompted!
-
Run
yarn packages:build
script that compiles distribution code inpackages/grafana-*/dist
. -
Run
yarn packages:pack
script to compress each package intonpm-artifacts/*.tgz
files. This is required for yarn to replace properties in the package.json files declared in thepublishConfig
property. -
Depending on whether or not it's a prerelease:
- When releasing a prerelease run
./scripts/publish-npm-packages.sh --dist-tag 'next' --registry 'https://registry.npmjs.org/'
to publish new versions. - When releasing a stable version run
./scripts/publish-npm-packages.sh --dist-tag 'latest' --registry 'https://registry.npmjs.org/'
to publish new versions. - When releasing a test version run
./scripts/publish-npm-packages.sh --dist-tag 'test' --registry 'https://registry.npmjs.org/'
to publish test versions.
- When releasing a prerelease run
-
Revert any changes made by the
packages:prepare
script.
Building individual packages
To build individual packages, run:
yarn packages:build --scope=@grafana/<data|e2e|e2e-selectors|runtime|schema|toolkit|ui>
Setting up @grafana/* packages for local development
A known issue with @grafana/* packages is that a lot of times we discover problems on canary channel(see versioning overview) when the version was already pushed to npm.
We can easily avoid that by setting up a local packages registry and test the packages before actually publishing to npm.
In this guide you will set up Verdaccio registry locally to fake npm registry. This will enable testing @grafana/* packages without the need for pushing to main.
Setting up local npm registry
From your terminal:
- Navigate to
devenv/local-npm
directory. - Run
docker-compose up
. This will start your local npm registry, available at http://localhost:4873/. Note the verdaccio config allows - To test
@grafana
packages published to your local npm registry uncommentnpmScopes
andunsafeHttpWhitelist
properties in the.yarnrc
file.
Publishing packages to local npm registry
You need to follow manual packages release procedure. The only difference is the last command in order to publish to you local registry.
From your terminal:
- Run
yarn packages:clean
. - Run
yarn packages:prepare
. - Run
yarn packages:build
. - Run
yarn packages:pack
. - Run
./scripts/publish-npm-packages.sh
. - Navigate to http://localhost:4873 and verify the version was published
Locally published packages will be published under dev
channel, so in your plugin package.json file you can use that channel. For example:
// plugin's package.json
dependencies: {
//... other dependencies
"@grafana/data": "dev"
}