mirror of
https://github.com/elastic/kibana.git
synced 2025-06-27 10:40:07 -04:00
Your window into the Elastic Stack
ac3fc27a53
## Summary This PR simplifies the weekly EUI upgrade and backport process by conditionally aliasing `@elastic/eui` in shared deps webpack configurations. # Backstory The EUI team (@elastic/eui-team) is responsible for keeping EUI up to date in Kibana. Historically, this has been a relatively straightforward (yet time-consuming) process, however, due to `8.x` backport complexities caused by it using a different theme, it has become way more demanding on everybody involved. EUI is released on weekly basis. Each week, we release official EUI versions tagged `latest` in npmjs and get a PR open that updates the package in kibana `main`. Our upgrade PRs tend to require anywhere between 2 and 25 codeowner reviews due to the number of snapshots we need to update while working on the EUI upgrade PRs. These snapshot changes are 99% of the time harmless, yet it still takes 2+ full workdays to ping teams and get all reviews necessary to get the PR merged. Generally speaking, we aim to have the upgrade PR open on Monday and merged by Friday. ## The issue with `8.x` backports Kibana 8.x uses the Amsterdam theme instead of Borealis, which is used in Kibana 9.0 and up. To keep 8.x up to date, for each official EUI release we prepare another special Kibana 8.x only release of EUI (e.g., `101.2.0-amsterdam.0`). These special releases have the theme hardcoded to Amsterdam at compile-time to avoid any initial theme errors Kibana could otherwise experience. This is done primarily because some areas in Kibana read EUI theme values outside of React components, and we have no stable way to determine what the active theme is since there's no context information. This is where we need to fall back to Amsterdam in 8.x and Borealis in 9.x. **Since there are two different EUI versions - one for Kibana `main` and 9.0, and another for 8.x branches, we cannot use the automated backports feature**. Instead, we open two separate PRs and configure backport labels accordingly. Having two PRs is far from ideal since codeowners need to review our changes twice, and we're more likely to make mistakes. # Our proposal Following the recently introduced React version switching logic, we want to conditionally switch between two `@elastic/eui` releases depending on the kibana branch/version while keeping automated backports possible. To achieve that, I added a dependency alias `@elastic/eui-amsterdam` that points to the Amsterdam EUI release and configured `resolve.alias` in shared deps to resolve the correct dependency based on the optional `EUI_AMSTERDAM` environment variable. When this change is merged to `main` and backported to `9.0` and `8.19`, I'll open a follow-up PR to the `8.19` branch updating the default value of `EUI_AMSTERDAM` to `"true"`. This should result in no conflicts and be easy to follow. Since 8.19 [uses the Amsterdam release of `@elastic/eui`](https://github.com/elastic/kibana/blob/8.19/package.json#L126) (e.g., `101.2.0-amsterdam.0`), there's no risk backporting this PR as-is without `EUI_AMSTERDAM` configured beforehand. ## What does it change? With this setup, we'll be able to update versions of `@elastic/eui` and `@elastic/eui-amsterdam` at the same time in a single PR and make use of automated kibana backports. There will be only one set of changes to review by codeowners, and if there are any failing tests when backporting to `8.19` due to, for example, changed color values, we can follow the regular kibana procedures and fix them right in the created backport PR. It'll simplify our workflow quite drastically while keeping the same level of quality. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> |
||
|---|---|---|
| .buildkite | ||
| .devcontainer | ||
| .github | ||
| api_docs | ||
| config | ||
| dev_docs | ||
| docs | ||
| examples | ||
| kbn_pm | ||
| legacy_rfcs | ||
| licenses | ||
| oas_docs | ||
| packages | ||
| plugins | ||
| scripts | ||
| src | ||
| typings | ||
| x-pack | ||
| .backportrc.json | ||
| .bazelignore | ||
| .bazeliskversion | ||
| .bazelrc | ||
| .bazelrc.common | ||
| .bazelversion | ||
| .browserslistrc | ||
| .editorconfig | ||
| .eslintignore | ||
| .eslintrc.js | ||
| .gitattributes | ||
| .gitignore | ||
| .i18nrc.json | ||
| .node-version | ||
| .npmrc | ||
| .nvmrc | ||
| .prettierignore | ||
| .prettierrc | ||
| .puppeteerrc | ||
| .stylelintignore | ||
| .stylelintrc | ||
| .telemetryrc.json | ||
| .yarnrc | ||
| BUILD.bazel | ||
| catalog-info.yaml | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| FAQ.md | ||
| fleet_packages.json | ||
| github_checks_reporter.json | ||
| kibana.d.ts | ||
| LICENSE.txt | ||
| NOTICE.txt | ||
| package.json | ||
| preinstall_check.js | ||
| README.md | ||
| renovate.json | ||
| RISK_MATRIX.mdx | ||
| run_fleet_setup_parallel.sh | ||
| SECURITY.md | ||
| sonar-project.properties | ||
| STYLEGUIDE.mdx | ||
| tsconfig.base.json | ||
| tsconfig.browser.json | ||
| tsconfig.browser_bazel.json | ||
| tsconfig.json | ||
| TYPESCRIPT.md | ||
| updatecli-compose.yaml | ||
| versions.json | ||
| WORKSPACE.bazel | ||
| yarn.lock | ||
Kibana
Kibana is your window into the Elastic Stack. Specifically, it's a browser-based analytics and search dashboard for Elasticsearch.
- Getting Started
- Documentation
- Version Compatibility with Elasticsearch
- Questions? Problems? Suggestions?
Getting Started
If you just want to try Kibana out, check out the Elastic Stack Getting Started Page to give it a whirl.
If you're interested in diving a bit deeper and getting a taste of Kibana's capabilities, head over to the Kibana Getting Started Page.
Using a Kibana Release
If you want to use a Kibana release in production, give it a test run, or just play around:
- Download the latest version on the Kibana Download Page.
- Learn more about Kibana's features and capabilities on the Kibana Product Page.
- We also offer a hosted version of Kibana on our Cloud Service.
Building and Running Kibana, and/or Contributing Code
You might want to build Kibana locally to contribute some code, test out the latest features, or try out an open PR:
- CONTRIBUTING.md will help you get Kibana up and running.
- If you would like to contribute code, please follow our STYLEGUIDE.mdx.
- For all other questions, check out the FAQ.md and wiki.
Documentation
Visit Elastic.co for the full Kibana documentation.
For information about building the documentation, see the README in elastic/docs.
Version Compatibility with Elasticsearch
Ideally, you should be running Elasticsearch and Kibana with matching version numbers. If your Elasticsearch has an older version number or a newer major number than Kibana, then Kibana will fail to run. If Elasticsearch has a newer minor or patch number than Kibana, then the Kibana Server will log a warning.
Note: The version numbers below are only examples, meant to illustrate the relationships between different types of version numbers.
| Situation | Example Kibana version | Example ES version | Outcome |
|---|---|---|---|
| Versions are the same. | 7.15.1 | 7.15.1 | 💚 OK |
| ES patch number is newer. | 7.15.0 | 7.15.1 | ⚠️ Logged warning |
| ES minor number is newer. | 7.14.2 | 7.15.0 | ⚠️ Logged warning |
| ES major number is newer. | 7.15.1 | 8.0.0 | 🚫 Fatal error |
| ES patch number is older. | 7.15.1 | 7.15.0 | ⚠️ Logged warning |
| ES minor number is older. | 7.15.1 | 7.14.2 | 🚫 Fatal error |
| ES major number is older. | 8.0.0 | 7.15.1 | 🚫 Fatal error |
Questions? Problems? Suggestions?
- If you've found a bug or want to request a feature, please create a GitHub Issue. Please check to make sure someone else hasn't already created an issue for the same topic.
- Need help using Kibana? Ask away on our Kibana Discuss Forum and a fellow community member or Elastic engineer will be glad to help you out.