mirror of
https://github.com/elastic/kibana.git
synced 2025-04-24 09:48:58 -04:00
Your window into the Elastic Stack
63e1e750dd
* [SIEM] Migrating frontend services to NP (#52783) * Remove legacy index_patterns import We'd already brought in the new interface in a previous commit; this was just used as an unnecessary type assertion. * Update snapshots following new docLink mocks * Remove unused manual mocks These are not picked up by jest; calling jest.mock('lib/compose/kibana_core') has the same effect whether or not these files exist. * WIP: Use kibana core mock everywhere we're doing it manually The timeline tests are the last place we're explicitly mocking useKibanaCore; removing the mocks cause tests to hang. I think hey're relying on the side effects of importing the mock/ui_settings file, but I'll figure that out next. * Replace ui/documentation_links with core NP service In most instances, this meant using the useContext hook with our NP core context. This also updates our mocks to leverage the factory so graciously provided by platform. There are a few failing tests, mostly due to links being previously undefined in tests. * Use new mocks on timeline test that doesn't hang The rest of these do, though. * Remove remaining uses of mockUiSettings in useKibanaCore mocks These have to be evaluated immediately so that we always return the same core object. Otherwise we get stuck in a loop between render/useEffect/setState due to the savedObjects client being different on each invocation. * Invoke platform's mock factory at mock time Previously, we were invoking it any time someone called `useKibanaCore`, getting a new object back each time. This both caused some bugs (looping with useEffect) and was not representative of how the actual hook worked. This also moves that invokation into the mock function, along with shaping the mocked module so that we don't have to do it in every call to jest.mock. * WIP: migrating to use kibana_react's provider and helpers We're re-exporting these locally to have more control around mocking them (until platform implements that). This breaks everything that was using the old mocks. Will fix. * WIP: Migrating to use kibana_react Instead of our homegrown hooks we can use these utilities instead. Unfortunately kibana_react doesn't yet have mocks, so we had to implement that ourselves. Luckily, we already had local mocks for the settings service. This migrates to a the new format. For clarity and consistency, we also re-export new platform's mocks here and use them to populate our kibana_react mocks. We started by migrating the UiSettings service to new platform, and let that drive the rest. With the mocks in place for kibana_react, removing the usage of useKibanaCore was a natural step as well. The next step is removing the usage of chrome.getUiSettingsClient with our useUiSetting$ hook, and with that (and maybe some config setup; I'm seeing errors at runtime), we should be ready to start migrating other services. * Bind a copy of kibana at mock creation We were previously returning a new copy any time e.g. useKibana was called, which is not the contract that consumers are expecting. and in fact caused looping with components employing useEffect etc. * Remove internal context providers and last usage We're now using kibana_react fully. * Fix tests failing due to wrong mocks Remaining failures are either due to a date format issue, or something being rendered differently. Those are up next. Still haven't touched use of chrome.getUiSettingsClient, that's after. * Fix test failures related to date formatting * mocks missing UI Setting (DEFAULT_TIMEZONE_BROWSER) which is required by our formatted_date utilities * mock timepicker ranges in the one test that uses it (SuperDatePicker) * Remove unnecessary and/or redundant mocks Since our TestProvider now mocks new platform, the only tests that should need to mock uiSettings related stuff (e.g. timezone preferences) would be the tests that (directly or no) use kibana_react to get it. * Refactor kibana_react mocks * adds a mock for the non-observable useUiSetting * removes the unmockable HOC withKibana * Replace usage of chrome.getUiSettingsClient with useUiSetting We're opting for the non-observable behavior here because I believe that's more analagous. There are a few remaining usages in non-react code. Tests are still using the mocks, those'll be removed next. * Remove ui_settings mocks Now that we're not using this hook there's no need for the mocks. Tests are green. * Remove siem's UI settings hook We're now using the ones provided by kibana_react. * Use withKibana HOC on our component classes React was kind enough to remind me that I can't put hooks in classes. Whoops. * Set defaults for some unknown UI settings The service claims not to know about these settings we're retrieving. Until I can figure out where they should come from, we're going to initialize them with what seem to be the defaults at plugin initialization. * Remove old hooks These have now been replaced with kibana_react's equivalents. * Fix type error on usage of useKibana hook This is one of the few places where we're using another plugin, which are not present in the default typings due to their opt-in nature. * Fix type error on ML call The indexPattern we get back is actually an array. The endpoint seems to handle this just fine (at least, it doesn't blow up), but once we started retrieving a typed value this error surfaced. * Export a 'bound' version of the useKibana function Rather than having to type this on each invocation. This requires us to define which plugins we depend on, which is a good thing. * Instantiate our mock function We aren't using these right now I didn't notice, but that wasn't the right reference. * Fix test that relies on unmocked service Our QueryBar component relies very (very, very) indirectly on a storage service that does not exist in New Platform, nor its corresponding mocks. To get it passing for now, we're just gonna pretend like it's there. * Remove use of ui/chrome in our charts Replaces with hooks that accomplish the same. * Remove last use of chrome.getUiSettingsClient This function is itself a hook, so we should be good here. * Remove unnecessary non-null assertions Now that we're using our typed version of the useKibana hook, typescript knows that these services will be available (once we actually enforce that in our kibana.json, of course). * Fix chart tests These rely on a kibana hook now, so we need to mock it out for these renders lest we blow up when the context isn't there. * Replace missing mock I deleted this in a previous commit, thinking it unneeded. However, getHostDetailsBreadcrumbs ultimately asks for some default date parameters for the timerange boundaries. * Add back tests for our theming hook * Style: cleanup * Remove unneeded default UI Settings values We were previously getting errors due to these values not being known to the client, but it looks like that was either fixed upstream, or a temporary issue caused by some improper context setup. * Simplify kibana_react mocks Let's leave JSX out of it. Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> * Update references to now-deleted hooks These hooks were deleted on a recent branch, but new usages were merged to master in the meantime. * Fix remaining uses of hooks/chrome that were not merge conflicts * Use HOC on class component Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> |
||
|---|---|---|
| .ci | ||
| .github | ||
| bin | ||
| common/graphql | ||
| config | ||
| data | ||
| docs | ||
| examples | ||
| licenses | ||
| packages | ||
| rfcs/text | ||
| scripts | ||
| src | ||
| style_guides | ||
| tasks | ||
| test | ||
| typings | ||
| utilities | ||
| vars | ||
| webpackShims | ||
| x-pack | ||
| .backportrc.json | ||
| .browserslistrc | ||
| .editorconfig | ||
| .eslintignore | ||
| .eslintrc.js | ||
| .gitattributes | ||
| .gitignore | ||
| .i18nrc.json | ||
| .node-version | ||
| .nvmrc | ||
| .prettierrc | ||
| .sass-lint.yml | ||
| .yarnrc | ||
| CONTRIBUTING.md | ||
| FAQ.md | ||
| github_checks_reporter.json | ||
| Gruntfile.js | ||
| Jenkinsfile | ||
| kibana.d.ts | ||
| LICENSE.txt | ||
| NOTICE.txt | ||
| package.json | ||
| preinstall_check.js | ||
| README.md | ||
| renovate.json5 | ||
| STYLEGUIDE.md | ||
| tsconfig.browser.json | ||
| tsconfig.json | ||
| tsconfig.types.json | ||
| TYPESCRIPT.md | ||
| 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.md.
- Learn more about our UI code with UI_SYSTEMS.md.
- 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. | 5.1.2 | 5.1.2 | 💚 OK |
| ES patch number is newer. | 5.1.2 | 5.1.5 | ⚠️ Logged warning |
| ES minor number is newer. | 5.1.2 | 5.5.0 | ⚠️ Logged warning |
| ES major number is newer. | 5.1.2 | 6.0.0 | 🚫 Fatal error |
| ES patch number is older. | 5.1.2 | 5.1.0 | ⚠️ Logged warning |
| ES minor number is older. | 5.1.2 | 5.0.0 | 🚫 Fatal error |
| ES major number is older. | 5.1.2 | 4.0.0 | 🚫 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.