* organize layout, make design uniform, add doc link * fix e2e test * move overhauled config parts into prometheus code * update tooltips with doc links * clean component styles for section padding, top and bottom 32px * make additional settings subsection headers h6 * use secondary gray for section descriptions * fix merge issues * change inlineswitch to switch only in prom settings because the other components are shared * remove legacy formfield and input, replace with inlinefield and input from grafana-ui * find more formfield and UI design fixes like changing inlineformlabel to inlinefield * remove unused inline form label * replace legacy duration validations with <FieldValidationMessage> * fix styles secondary gray from theme * change language, headings and datasource -> data source * update alert setting styles with new component * update prom url heading and tooltip * update default editor tooltip and set builder as default editor * update interval tooltip * update prom type tooltip * update custom query params tooltip * update exemplar internal link tooltip * fix inline form styling inconsistency * allow for using the DataSourceHTTPSettings component without the connection string * remove overhaul component, re-use dshtttps comp, and use connection input in config editor * make tooltips interactive to click links * consistent label width across the elements we can control for now, fix exemplar switch * make connection url a component * refactor onBlur validation * remove unused component * add tests for config validations * add more meaningful health check * fix e2e test * fix e2e test * fix e2e test * add error handling for more url errors * remove unnecessary conversion * health check tests * Clean up the health check * health check unit tests * health check unit tests improved * make pretty for drone * lint check go * lint check go * add required attr to connection component * Update public/app/plugins/datasource/prometheus/configuration/Connection.tsx Co-authored-by: Torkel Ödegaard <torkel@grafana.com> * fix read only issue for provisioned datasources * validate multiple durations for incremental query setting * use sentence case for headers * use className consistently for styles * add tests for url regex * remove console logs * only use query as healthcheck as the healthy api is not supported by Mimir * fix exemplar e2e test * remove overhaul prop from custom headers setting component * remove connection section and use DatasourceHttpSettings connection with custom label and interactive tooltip * add spaces back * spaces --------- Co-authored-by: ismail simsek <ismailsimsek09@gmail.com> Co-authored-by: Torkel Ödegaard <torkel@grafana.com>
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:cleanscript from the root directory. This will delete any previous builds of the packages. -
Run
yarn packages:preparescript 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:buildscript that compiles distribution code inpackages/grafana-*/dist. -
Run
yarn packages:packscript to compress each package intonpm-artifacts/*.tgzfiles. This is required for yarn to replace properties in the package.json files declared in thepublishConfigproperty. -
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:preparescript.
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-npmdirectory. - Run
docker-compose up. This will start your local npm registry, available at http://localhost:4873/. Note the verdaccio config allows - To test
@grafanapackages published to your local npm registry uncommentnpmScopesandunsafeHttpWhitelistproperties in the.yarnrcfile.
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"
}