Merge branch 'master' into avoid-non-null-assertions

elastic · Oct 7, 2021 · 5d80c8d · 5d80c8d
2 parents 20be009 + 0442c87
commit 5d80c8d
Show file tree

Hide file tree

Showing 167 changed files with 1,688 additions and 1,086 deletions.
diff --git a/.bazelrc b/.bazelrc
@@ -2,12 +2,13 @@
 # Import shared settings first so we can override below
 import %workspace%/.bazelrc.common
 
-## Disabled for now
 # Remote cache settings for local env
-# build --remote_cache=https://storage.googleapis.com/kibana-bazel-cache
-# build --incompatible_remote_results_ignore_disk=true
-# build --remote_accept_cached=true
-# build --remote_upload_local_results=false
+build --remote_cache=grpcs://cloud.buildbuddy.io
+build --incompatible_remote_results_ignore_disk=true
+build --noremote_upload_local_results
+build --remote_timeout=30
+build --remote_header=x-buildbuddy-api-key=3EYk49W2NefOx2n3yMze
+build --remote_accept_cached=true
 
 # BuildBuddy
 ## Metadata settings

diff --git a/.buildkite/scripts/common/setup_bazel.sh b/.buildkite/scripts/common/setup_bazel.sh
diff --git a/.buildkite/scripts/lifecycle/pre_command.sh b/.buildkite/scripts/lifecycle/pre_command.sh
@@ -89,7 +89,6 @@ if [[ "${SKIP_CI_SETUP:-}" != "true" ]]; then
   if [[ -d .buildkite/scripts && "${BUILDKITE_COMMAND:-}" != "buildkite-agent pipeline upload"* ]]; then
     source .buildkite/scripts/common/env.sh
     source .buildkite/scripts/common/setup_node.sh
-    source .buildkite/scripts/common/setup_bazel.sh
   fi
 fi
 

diff --git a/.buildkite/scripts/steps/on_merge_build_and_metrics.sh b/.buildkite/scripts/steps/on_merge_build_and_metrics.sh
@@ -2,6 +2,9 @@
 
 set -euo pipefail
 
+# Write Bazel cache for Linux
+.buildkite/scripts/common/setup_bazel.sh
+
 .buildkite/scripts/bootstrap.sh
 .buildkite/scripts/build_kibana.sh
 .buildkite/scripts/post_build_kibana.sh

diff --git a/dev_docs/api_welcome.mdx b/dev_docs/api_welcome.mdx
@@ -58,7 +58,7 @@ type Bar = { id: string };
 export type Foo = Bar | string;
 ```
 
-`Bar`, in the signature of `Foo`, will not be clickable because it would result in a broken link. `Bar` is not publically exported!
+`Bar`, in the signature of `Foo`, will not be clickable because it would result in a broken link. `Bar` is not publicly exported!
 
 If that isn't the case, please file an issue, it could be a bug with the system.
 

diff --git a/dev_docs/contributing/best_practices.mdx b/dev_docs/contributing/best_practices.mdx
@@ -196,7 +196,7 @@ Over-refactoring can be a problem in it's own right, but it's still important to
 Try not to put your PR in review mode, or merge large changes, right before Feature Freeze. It's inevitably one of the most volatile times for the
 Kibana code base, try not to contribute to this volatility. Doing this can:
 
-- increase the likelyhood of conflicts from other features being merged at the last minute
+- increase the likelihood of conflicts from other features being merged at the last minute
 - means your feature has less QA time
 - means your feature gets less careful review as reviewers are often swamped at this time
 

diff --git a/dev_docs/contributing/code_walkthrough.mdx b/dev_docs/contributing/code_walkthrough.mdx
@@ -0,0 +1,139 @@
+---
+id: kibRepoStructure
+slug: /kibana-dev-docs/contributing/repo-structure
+title: Repository structure
+summary: High level walk-through of our repository structure.
+date: 2021-10-07
+tags: ['contributor', 'dev', 'github', 'getting started', 'onboarding', 'kibana']
+---
+
+A high-level walk through of the folder structure of our [repository](https://github.com/elastic/kibana).
+
+Tip: Look for a `README.md` in a folder to learn about its contents.
+
+## [.buildkite](https://github.com/elastic/kibana/tree/master/.buildkite)
+
+Managed by the operations team to set up a new buildkite ci system. Can be ignored by folks outside the Operations team.
+
+## [.ci](https://github.com/elastic/kibana/tree/master/.ci) 
+
+Managed by the operations team to contain Jenkins settings. Can be ignored by folks outside the Operations team.
+
+## [.github](https://github.com/elastic/kibana/tree/master/.github)
+
+Contains GitHub configuration settings. This file contains issue templates, and the [CODEOWNERS](https://github.com/elastic/kibana/blob/master/.github/CODEOWNERS) file. It's important for teams to keep the CODEOWNERS file up-to-date so the right team is pinged for a code owner review on PRs that edit certain files. Note that the `CODEOWNERS` file only exists on the main/master branch, and is not backported to other branches in the repo.
+
+## [api_docs](https://github.com/elastic/kibana/tree/master/api_docs)
+
+Every file in here is auto-generated by the <DocLink id="kibDevDocsApiWelcome" text="API Docs system"/> and used to render our API documentation. If you edit a public plugin or package API and run `node scripts/build_api_docs` you will see files changed in this folder. Do not edit the contents of this folder directly!
+
+Note that currently you may see _a lot_ of changes because that command is not run on every PR and so the content in this folder is often outdated.
+
+## [config](https://github.com/elastic/kibana/tree/master/config)
+
+This contains the base configuration file, `kibana.yml`. If you want to tweak any settings, create a `kibana.dev.yml` in here which will get picked up during development, and not checked into GitHub.
+
+## [docs](https://github.com/elastic/kibana/tree/master/docs)
+
+Every folder in here _except_ the [development one](https://github.com/elastic/kibana/tree/master/docs/development) contains manually generated asciidocs that end up hosted in our [Elastic guide](https://www.elastic.co/guide/).
+
+The `development` folder contains markdown that is auto-generated with our legacy API docs tool. We are aiming to remove it shortly after 8.0FF.
+
+## [dev_docs](https://github.com/elastic/kibana/tree/master/dev_docs)
+
+This is where a lot of manually written content for our Developer Guide resides. Developers may also keep the information closer to what it's describing, but it's a good spot for high-level information, or information that describes how multiple plugins work together.
+
+## [examples](https://github.com/elastic/kibana/tree/master/examples)
+
+These are our tested example plugins that also get built and hosted [here](https://demo.kibana.dev/8.0/app/developerExamples). If a plugin is written for testing purposes only, it won't go in here. These example plugins should be written with the intention of helping developers understand how to use our services.
+
+## [legacy_rfcs](https://github.com/elastic/kibana/tree/master/legacy_rfcs)
+
+We used to write RFCs in `md` format and keep them in the repository, but we have since moved to Google Docs. We kept the folder around, since some folks still read these old docs. If you are an internal contributor you can visit <DocLink id="ktRFCProcess" text="this document"/> to read about our current RFC process.
+
+## [licenses](https://github.com/elastic/kibana/tree/master/licenses)
+
+Contains our two license header texts, one for the Elastic license and one for the Elastic+SSPL license. All code files inside x-pack should have the Elastic license text at the top, all code files outside x-pack should contain the other. If you have your environment set up to auto-fix on save, eslint should take care of adding it for you. If you don't have it, ci will fail. Can be ignored for the most part, this rarely changes.
+
+## [packages](https://github.com/elastic/kibana/tree/master/packages)
+
+The packages folder contains a mixture of build-time related code (like the [code needed to build the api docs](https://github.com/elastic/kibana/tree/master/packages/kbn-docs-utils)), as well as static code that some plugins rely on (like the [kbn-monaco package](https://github.com/elastic/kibana/tree/master/packages/kbn-monaco)). <DocLink id="kibPlatformIntro" section="1000-foot-view" text="This document"/> covers how packages differ from plugins.
+
+## [plugins](https://github.com/elastic/kibana/tree/master/plugins)
+
+This is an empty folder in GitHub. It's where third party developers should put their plugin folders. Internal developers can ignore this folder.
+
+## [scripts](https://github.com/elastic/kibana/tree/master/scripts)
+
+Contains a bunch of developer scripts. These are usually very small files with just two lines that kick off a command, the logic of which resides elsewhere (sometimes `src/dev`, sometimes inside `packages`).
+Example:
+```
+require('../src/setup_node_env');
+require('@kbn/es-archiver').runCli();
+```
+
+## [src](https://github.com/elastic/kibana/tree/master/src)
+
+This folder and the packages folder contain the most code and where developers usually find themselves. I'll touch on a few of the subfolder, the rest can generally be ignored, or are build/ops related code.
+
+### [src/cli*](https://github.com/elastic/kibana/tree/master/src/cli)
+
+Maintained primarily by the Operations team, this folder contains code that initializes the Kibana runtime and a bit of work to handle authorization for interactive setup mode.  Most devs should be able to ignore this code.
+
+### [src/core](https://github.com/elastic/kibana/tree/master/src/core)
+
+This code primarily belongs to the Core team and contains the plugin infrastructure, as well as a bunch of fundamental services like migrations, saved objects, and some UI utilities (toasts, flyouts, etc.).
+
+### [src/dev](https://github.com/elastic/kibana/tree/master/src/dev)
+
+Maintained by the Operations team, this code contains build and development tooling related code. This folder existed before `packages`, so contains mostly older code that hasn't been migrated to packages. Prefer creating a `package` if possible. Can be ignored for the most part if you are not on the Ops team. Prefer 
+
+### [src/plugins](https://github.com/elastic/kibana/tree/master/src/plugins)
+
+Contains all of our Basic-licensed plugins. Most folders in this directory will contain `README.md` files explaining what they do. If there are none, you can look at the `owner.gitHub` field inside all `kibana.json`s that will tell you which team to get in touch with for questions.
+
+Note that as plugins can be nested, each folder in this directory may contain multiple plugins.
+
+## [test](https://github.com/elastic/kibana/tree/master/test)
+
+Contains functional tests and related FTR (functional test runner) code for the plugins inside `src/plugins`, although there is a push to move the tests to reside inside the plugins themselves.
+
+## [typings](https://github.com/elastic/kibana/tree/master/typings)
+
+Maintained by Ops and Core, this contains global typings for dependencies that do not provide their own types, or don't have types available via [DefinitelyTyped](https://definitelytyped.org). This directory is intended to be minimal; types should only be added here as a last resort.
+
+## [vars](https://github.com/elastic/kibana/tree/master/vars)
+
+A bunch of groovy scripts maintained by the Operations team.
+
+## [x-pack](https://github.com/elastic/kibana/tree/master/x-pack)
+
+Contains all code and infrasturcture that powers our gold+ (non-basic) features that are provided under a more restrictive license.
+
+### [x-pack/build_chromium](https://github.com/elastic/kibana/tree/master/x-pack/build_chromium)
+
+Maintained by the App Services UX team, this contains Reporting-related code for building Chromium in order to take server side screenshots.
+
+### [x-pack/dev-tools](https://github.com/elastic/kibana/tree/master/x-pack/dev-tools)
+
+Maintained by the Operations team.
+
+### [x-pack/examples](https://github.com/elastic/kibana/tree/master/x-pack/examples)
+
+Contains all example plugins that rely on gold+ features.
+
+### [x-pack/plugins](https://github.com/elastic/kibana/tree/master/x-pack/plugins)
+
+Contains code for all the plugins that power our gold+ features.
+
+### [x-pack/scripts](https://github.com/elastic/kibana/tree/master/x-pack/scripts)
+
+Maintained by the Ops team, this folder contains some scripts for running x-pack utilities, like the functional test runner that runs with a license higher than Basic.
+
+### [x-pack/test](https://github.com/elastic/kibana/tree/master/x-pack/test)
+
+Functional tests for our gold+ features.
+
+
+
+
diff --git a/dev_docs/getting_started/setting_up_a_development_env.mdx b/dev_docs/getting_started/setting_up_a_development_env.mdx
@@ -44,7 +44,7 @@ Then, install the latest version of yarn using:
 npm install -g yarn
 ```
 
-Finally, boostrap Kibana and install all of the remaining dependencies:
+Finally, bootstrap Kibana and install all of the remaining dependencies:
 
 ```sh
 yarn kbn bootstrap

diff --git a/dev_docs/key_concepts/saved_objects.mdx b/dev_docs/key_concepts/saved_objects.mdx
@@ -33,7 +33,7 @@ all the "children" will be automatically included. However, when a "child" is ex
 
 ## Migrations and Backward compatibility
 
-As your plugin evolves, you may need to change your Saved Object type in a breaking way (for example, changing the type of an attribtue, or removing
+As your plugin evolves, you may need to change your Saved Object type in a breaking way (for example, changing the type of an attribute, or removing
 an attribute). If that happens, you should write a migration to upgrade the Saved Objects that existed prior to the change.
 
 <DocLink id="kibDevTutorialSavedObject" section="migrations" text="How to write a migration" />.

diff --git a/dev_docs/tutorials/data/search.mdx b/dev_docs/tutorials/data/search.mdx
@@ -477,7 +477,7 @@ If you don't call `clear`, you will see a warning in the console while developin
 
 The last step of the integration is restoring an existing search session. The `searchSessionId` parameter and the rest of the restore state are passed into the application via the URL. Non-URL support is planned for future releases.
 
-If you detect the presense of a `searchSessionId` parameter in the URL, call the `restore` method **instead** of calling `start`. The previous example would now become:
+If you detect the presence of a `searchSessionId` parameter in the URL, call the `restore` method **instead** of calling `start`. The previous example would now become:
 
 ```ts
 function onSearchSessionConfigChange(searchSessionIdFromUrl?: string) {

diff --git a/docs/api/spaces-management/copy_saved_objects.asciidoc b/docs/api/spaces-management/copy_saved_objects.asciidoc
@@ -58,7 +58,7 @@ You can request to overwrite any objects that already exist in the target space
 NOTE: This cannot be used with the `overwrite` option.
 
 `overwrite`::
-  (Optional, boolean) When set to `true`, all conflicts are automatically overidden. When a saved object with a matching `type` and `id`
+  (Optional, boolean) When set to `true`, all conflicts are automatically overridden. When a saved object with a matching `type` and `id`
   exists in the target space, that version is replaced with the version from the source space. The default value is `false`.
 +
 NOTE: This cannot be used with the `createNewCopies` option.

diff --git a/docs/developer/advanced/upgrading-nodejs.asciidoc b/docs/developer/advanced/upgrading-nodejs.asciidoc
@@ -5,7 +5,7 @@
 When running {kib} from source, you must have this version installed locally.
 
 The required version of Node.js is listed in several different files throughout the {kib} source code.
-Theses files must be updated when upgrading Node.js:
+These files must be updated when upgrading Node.js:
 
   - {kib-repo}blob/{branch}/.ci/Dockerfile[`.ci/Dockerfile`] - The version is specified in the `NODE_VERSION` constant.
     This is used to pull the relevant image from https://hub.docker.com/_/node[Docker Hub].
@@ -29,7 +29,7 @@ The following rules are not set in stone.
 Use best judgement when backporting.
 
 Currently version 7.11 and newer run Node.js 14, while 7.10 and older run Node.js 10.
-Hence, upgrades to either Node.js 14 or Node.js 10 shold be done as separate PRs.
+Hence, upgrades to either Node.js 14 or Node.js 10 should be done as separate PRs.
 
 ==== Node.js patch upgrades
 

diff --git a/docs/developer/architecture/security/rbac.asciidoc b/docs/developer/architecture/security/rbac.asciidoc
@@ -104,6 +104,6 @@ Authorization: Basic foo_read_only_user password
 }
 ----------------------------------
 
-{es} checks if the user is granted a specific action. If the user is assigned a role that grants a privilege, {es} uses the <<development-rbac-privileges, {kib} privileges>> definition to associate this with the actions, which makes authorizing users more intuitive and flexible programatically.
+{es} checks if the user is granted a specific action. If the user is assigned a role that grants a privilege, {es} uses the <<development-rbac-privileges, {kib} privileges>> definition to associate this with the actions, which makes authorizing users more intuitive and flexible programmatically.
 
 Once we have authorized the user to perform a specific action, we can execute the request using `callWithInternalUser`.
diff --git a/docs/developer/best-practices/typescript.asciidoc b/docs/developer/best-practices/typescript.asciidoc
@@ -47,7 +47,7 @@ Additionally, in order to migrate into project refs, you also need to make sure
     "declarationMap": true
   },
   "include": [
-    // add all the folders containg files to be compiled
+    // add all the folders containing files to be compiled
   ],
   "references": [
     { "path": "../../core/tsconfig.json" },

diff --git a/docs/developer/contributing/development-ci-metrics.asciidoc b/docs/developer/contributing/development-ci-metrics.asciidoc
@@ -67,7 +67,7 @@ You can report new metrics by using the `CiStatsReporter` class provided by the
 
 In order to prevent the page load bundles from growing unexpectedly large we limit the `page load asset size` metric for each plugin. When a PR increases this metric beyond the limit defined for that plugin in {kib-repo}blob/{branch}/packages/kbn-optimizer/limits.yml[`limits.yml`] a failed commit status is set and the PR author needs to decide how to resolve this issue before the PR can be merged.
 
-In most cases the limit should be high enough that PRs shouldn't trigger overages, but when they do make sure it's clear what is cuasing the overage by trying the following:
+In most cases the limit should be high enough that PRs shouldn't trigger overages, but when they do make sure it's clear what is causing the overage by trying the following:
 
 1. Run the optimizer locally with the `--profile` flag to produce webpack `stats.json` files for bundles which can be inspected using a number of different online tools. Focus on the chunk named `{pluginId}.plugin.js`; the `*.chunk.js` chunks make up the `async chunks size` metric which is currently unlimited and is the main way that we <<plugin-performance, reduce the size of page load chunks>>.
 +
@@ -107,7 +107,7 @@ prettier -w {pluginDir}/target/public/{pluginId}.plugin.js
 
 Once you've identified the files which were added to the build you likely just need to stick them behind an async import as described in <<plugin-performance, Plugin performance>>.
 
-In the case that the bundle size is not being bloated by anything obvious, but it's still larger than the limit, you can raise the limit in your PR. Do this either by editting the {kib-repo}blob/{branch}/packages/kbn-optimizer/limits.yml[`limits.yml` file] manually or by running the following to have the limit updated to the current size + 15kb
+In the case that the bundle size is not being bloated by anything obvious, but it's still larger than the limit, you can raise the limit in your PR. Do this either by editing the {kib-repo}blob/{branch}/packages/kbn-optimizer/limits.yml[`limits.yml` file] manually or by running the following to have the limit updated to the current size + 15kb
 
 [source,shell]
 -----------

diff --git a/docs/developer/contributing/development-functional-tests.asciidoc b/docs/developer/contributing/development-functional-tests.asciidoc
@@ -185,8 +185,8 @@ node scripts/functional_test_runner --config test/functional/config.firefox.js
 [discrete]
 ==== Using the test_user service
 
-Tests should run at the positive security boundry condition, meaning that they should be run with the mimimum privileges required (and documented) and not as the superuser.
- This prevents the type of regression where additional privleges accidentally become required to perform the same action. 
+Tests should run at the positive security boundary condition, meaning that they should be run with the minimum privileges required (and documented) and not as the superuser.
+ This prevents the type of regression where additional privileges accidentally become required to perform the same action. 
 
 The functional UI tests now default to logging in with a user named `test_user` and the roles of this user can be changed dynamically without logging in and out.  
 
@@ -458,7 +458,7 @@ Bad example: `PageObjects.app.clickButton()`
 class AppPage {
   // what can people who call this method expect from the
   // UI after the promise resolves? Since the reaction to most
-  // clicks is asynchronous the behavior is dependant on timing
+  // clicks is asynchronous the behavior is dependent on timing
   // and likely to cause test that fail unexpectedly
   async clickButton () {
     await testSubjects.click(‘menuButton’);

diff --git a/docs/developer/contributing/development-tests.asciidoc b/docs/developer/contributing/development-tests.asciidoc
@@ -51,7 +51,7 @@ Any additional options supplied to `test:jest` will be passed onto the Jest CLI
 ----
 kibana/src/plugins/dashboard/server$ yarn test:jest --coverage
 
-# is equivelant to
+# is equivalent to
 
 yarn jest --coverage --verbose --config /home/tyler/elastic/kibana/src/plugins/dashboard/jest.config.js server
 ----

diff --git a/docs/developer/plugin/migrating-legacy-plugins-examples.asciidoc b/docs/developer/plugin/migrating-legacy-plugins-examples.asciidoc
@@ -486,7 +486,7 @@ to change the application or the navlink state at runtime.
 
 [source,typescript]
 ----
-// my_plugin has a required dependencie to the `licensing` plugin
+// my_plugin has a required dependency to the `licensing` plugin
 interface MyPluginSetupDeps {
   licensing: LicensingPluginSetup;
 }

diff --git a/.../development/core/public/kibana-plugin-core-public.appnavoptions.euiicontype.md b/.../development/core/public/kibana-plugin-core-public.appnavoptions.euiicontype.md
@@ -4,7 +4,7 @@
 
 ## AppNavOptions.euiIconType property
 
-A EUI iconType that will be used for the app's icon. This icon takes precendence over the `icon` property.
+A EUI iconType that will be used for the app's icon. This icon takes precedence over the `icon` property.
 
 <b>Signature:</b>