Merge branch 'main' into searchstrat_audit_log

.backportrc.json

@@ -1,7 +1,7 @@
 {
   "upstream": "elastic/kibana",
   "targetBranchChoices": [
-    { "name": "master", "checked": true },
+    { "name": "main", "checked": true },
     "8.0",
     "7.16",
     "7.15",
@@ -33,7 +33,7 @@
   ],
   "targetPRLabels": ["backport"],
   "branchLabelMapping": {
-    "^v8.1.0$": "master",
+    "^v8.1.0$": "main",
     "^v(\\d+).(\\d+).\\d+$": "$1.$2"
   },
   "autoMerge": true,

.buildkite/scripts/steps/es_snapshots/build.sh

@@ -14,6 +14,10 @@ mkdir -p "$destination"
 mkdir -p elasticsearch && cd elasticsearch
 
 export ELASTICSEARCH_BRANCH="${ELASTICSEARCH_BRANCH:-$BUILDKITE_BRANCH}"
+# Until ES renames their master branch to main...
+if [[ "$ELASTICSEARCH_BRANCH" == "main" ]]; then
+  export ELASTICSEARCH_BRANCH="master"
+fi
 
 if [[ ! -d .git ]]; then
   git init

.ci/packer_cache.sh

@@ -7,5 +7,5 @@ if [[ "$(which docker)" != "" && "$(command uname -m)" != "aarch64" ]]; then
   docker pull "maven:3.6.3-openjdk-8-slim"
 fi
 
-./.ci/packer_cache_for_branch.sh master
+./.ci/packer_cache_for_branch.sh main
 ./.ci/packer_cache_for_branch.sh 7.16

.ci/packer_cache_for_branch.sh

@@ -7,7 +7,7 @@ checkoutDir="$(pwd)"
 
 function cleanup()
 {
-  if [[ "$branch" != "master" ]]; then
+  if [[ "$branch" != "main" ]]; then
     rm --preserve-root -rf "$checkoutDir"
   fi
 
@@ -16,7 +16,7 @@ function cleanup()
 
 trap 'cleanup' 0
 
-if [[ "$branch" != "master" ]]; then
+if [[ "$branch" != "main" ]]; then
   checkoutDir="/tmp/kibana-$branch"
   git clone https://github.com/elastic/kibana.git --branch "$branch" --depth 1 "$checkoutDir"
   cd "$checkoutDir"

.github/ISSUE_TEMPLATE/v8_breaking_change.md

@@ -37,7 +37,7 @@ changes to Upgrade Assistant itself, please tag Team:Elasticsearch UI.
 
 **Are there any edge cases?**
 
-**[For Kibana deprecations] Can the change be registered with the [Kibana deprecation service](https://github.com/elastic/kibana/blob/master/docs/development/core/server/kibana-plugin-core-server.deprecationsservicesetup.md)?**
+**[For Kibana deprecations] Can the change be registered with the [Kibana deprecation service](https://github.com/elastic/kibana/blob/main/docs/development/core/server/kibana-plugin-core-server.deprecationsservicesetup.md)?**
 
 <!-- The deprecation service is consumed by the Upgrade Assistant to surface Kibana deprecations.
   It provides a way for Kibana deprecations to be resolved automatically via an API

.github/PULL_REQUEST_TEMPLATE.md

@@ -7,12 +7,12 @@ Summarize your PR. If it involves visual changes include a screenshot or gif.
 
 Delete any items that are not applicable to this PR.
 
-- [ ] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/master/packages/kbn-i18n/README.md)
+- [ ] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
 - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials
 - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
 - [ ] Any UI touched in this PR is usable by keyboard only (learn more about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
 - [ ] Any UI touched in this PR does not create any new axe failures (run axe in browser: [FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/), [Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
-- [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/master/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
+- [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
 - [ ] This renders correctly on smaller devices using a responsive layout. (You can test this [in your browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
 - [ ] This was checked for [cross-browser compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
 
@@ -30,7 +30,7 @@ When forming the risk matrix, consider some of the following examples and how th
 | Multiple Spaces—unexpected behavior in non-default Kibana Space. | Low | High | Integration tests will verify that all features are still supported in non-default Kibana Space and when user switches between spaces. |
 | Multiple nodes—Elasticsearch polling might have race conditions when multiple Kibana nodes are polling for the same tasks. | High | Low | Tasks are idempotent, so executing them multiple times will not result in logical error, but will degrade performance. To test for this case we add plenty of unit tests around this logic and document manual testing procedure. |
 | Code should gracefully handle cases when feature X or plugin Y are disabled. | Medium | High | Unit tests will verify that any feature flag or plugin combination still results in our service operational. |
-| [See more potential risk examples](https://github.com/elastic/kibana/blob/master/RISK_MATRIX.mdx) |
+| [See more potential risk examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
 
 
 ### For maintainers

.github/workflows/backport.yml

@@ -1,7 +1,7 @@
 on:
   pull_request_target:
     branches:
-      - master
+      - main
     types:
       - labeled
       - closed

.github/workflows/fix-version-gaps.yml

@@ -1,7 +1,7 @@
 on:
   pull_request:
     branches:
-      - master
+      - main
     types:
       - closed
 

STYLEGUIDE.mdx

@@ -210,7 +210,7 @@ less likely to introduce bugs in the future due to insufficient types.
 
 If you’re not having `any` in your plugin or are starting a new plugin, you should enable the
 [`@typescript-eslint/no-explicit-any`](https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-explicit-any.md)
-linting rule for your plugin via the [`.eslintrc.js`](https://github.com/elastic/kibana/blob/master/.eslintrc.js) config.
+linting rule for your plugin via the [`.eslintrc.js`](https://github.com/elastic/kibana/blob/main/.eslintrc.js) config.
 
 ### Avoid non-null assertions
 
@@ -229,7 +229,7 @@ assertion would now wrongly disable proper type checking for us.
 
 If you’re not using non-null assertions in your plugin or are starting a new plugin, consider enabling the
 [`@typescript-eslint/no-non-null-assertion`](https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-non-null-assertion.md)
-linting rule for you plugin in the [`.eslintrc.js`](https://github.com/elastic/kibana/blob/master/.eslintrc.js) config.
+linting rule for you plugin in the [`.eslintrc.js`](https://github.com/elastic/kibana/blob/main/.eslintrc.js) config.
 
 ### Return/throw early from functions
 
@@ -623,7 +623,7 @@ by your code until the circular dependencies on these have been solved.
 
 When writing a new component, create a sibling SASS file of the same name and import directly into the **top** of the JS/TS component file. Doing so ensures the styles are never separated or lost on import and allows for better modularization (smaller individual plugin asset footprint).
 
-All SASS (.scss) files will automatically build with the [EUI](https://elastic.github.io/eui/#/guidelines/sass) & Kibana invisibles (SASS variables, mixins, functions) from the [`globals_[theme].scss` file](src/core/public/core_app/styles/_globals_v7light.scss).
+All SASS (.scss) files will automatically build with the [EUI](https://elastic.github.io/eui/#/guidelines/sass) & Kibana invisibles (SASS variables, mixins, functions) from the [`globals_[theme].scss` file](src/core/public/core_app/styles/_globals_v8light.scss).
 
 While the styles for this component will only be loaded if the component exists on the page,
 the styles **will** be global and so it is recommended to use a three letter prefix on your

dev_docs/api_welcome.mdx

@@ -12,7 +12,7 @@ documentation for every plugin that exposes a <DocLink id="kibPlatformIntro" sec
 
 <DocCallOut color="warning" title="Experimental">
 This documentation is being automatically generated using an
- [_experimental_ system](https://github.com/elastic/kibana/blob/master/rfcs/text/0014_api_documentation.md). That means
+ [_experimental_ system](https://github.com/elastic/kibana/blob/main/rfcs/text/0014_api_documentation.md). That means
  it may be removed or modified at any time. If you have any questions, feedback or concerns, please create an issue using
   the label `APIDocs`, or reach out to the Kibana Tech Leads
  who are temporarily owning and maintaining this system.
@@ -46,7 +46,7 @@ the instructions <DocLink id="docsSetup" section="configure-the-nav-for-your-con
 configure the navigation menu.  The nav file you need to
  edit is: [https://github.com/elastic/elastic-docs/blob/master/config/nav-kibana-dev.ts](https://github.com/elastic/elastic-docs/blob/master/config/nav-kibana-dev.ts)
 
-Your API docs will exist in the top level [`api_docs` folder](https://github.com/elastic/kibana/tree/master/api_docs) and will use a doc id of the pattern `kib${PluginName}PluginApi`.
+Your API docs will exist in the top level [`api_docs` folder](https://github.com/elastic/kibana/tree/main/api_docs) and will use a doc id of the pattern `kib${PluginName}PluginApi`.
 
 ### Why is a referenced API item not showing up as clickable?
 
@@ -70,7 +70,7 @@ In the short term, the best thing you can do is avoid deeply nested API items. U
 adding `serviceFolders` in your kibana.json. This will automatically split your docs up based on which APIs are defined within the service folders.
 They will get built into a doc with an id of
 `kib${PluginName}${ServiceName}PluginApi`. The data plugin does this, so you
- can [check that out as an example](https://github.com/elastic/kibana/blob/master/src/plugins/data/kibana.json#L13).
+ can [check that out as an example](https://github.com/elastic/kibana/blob/main/src/plugins/data/kibana.json#L13).
 
  If that isn't the case and you are still experiencing performance issues, please file an issue!
 

dev_docs/contributing/best_practices.mdx

@@ -29,7 +29,7 @@ Refer to [divio documentation](https://documentation.divio.com/) for guidance on
 
 #### Location
 
-If the information spans multiple plugins, consider adding it to the [dev_docs](https://github.com/elastic/kibana/tree/master/dev_docs) folder. If it is plugin specific, consider adding it inside the plugin folder. Write it in an mdx file if you would like it to show up in our new (beta) documentation system.
+If the information spans multiple plugins, consider adding it to the [dev_docs](https://github.com/elastic/kibana/tree/main/dev_docs) folder. If it is plugin specific, consider adding it inside the plugin folder. Write it in an mdx file if you would like it to show up in our new (beta) documentation system.
 
 <DocCallOut title="internal only">
 
@@ -139,7 +139,7 @@ export type foo: string | AnInterface;
 
 ### Example plugins
 
-Running Kibana with `yarn start --run-examples` will include all [example plugins](https://github.com/elastic/kibana/tree/master/examples). These are tested examples of platform services in use. We strongly encourage anyone providing a platform level service or <DocLink id="kibBuildingBlocks" text="building block"/> to include a tutorial that links to a tested example plugin. This is better than relying on copied code snippets, which can quickly get out of date.
+Running Kibana with `yarn start --run-examples` will include all [example plugins](https://github.com/elastic/kibana/tree/main/examples). These are tested examples of platform services in use. We strongly encourage anyone providing a platform level service or <DocLink id="kibBuildingBlocks" text="building block"/> to include a tutorial that links to a tested example plugin. This is better than relying on copied code snippets, which can quickly get out of date.
 
 ## Performance
 
@@ -165,15 +165,15 @@ all of our apps are accessible.
 
 ## Localization
 
-Kibana is translated into other languages. Use our i18n utilities to ensure your public facing strings will be translated to ensure all Kibana apps are localized. Read and adhere to our [i18n guidelines](https://github.com/elastic/kibana/blob/master/packages/kbn-i18n/GUIDELINE.md)
+Kibana is translated into other languages. Use our i18n utilities to ensure your public facing strings will be translated to ensure all Kibana apps are localized. Read and adhere to our [i18n guidelines](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/GUIDELINE.md)
 
 <DocCallOut title="Internal only">
   Elasticians, check out the #kibana-localization channel to ask questions and receive guidance.
 </DocCallOut>
 
 ## Styleguide
 
-We use es-lint rules when possible, but please review our [styleguide](https://github.com/elastic/kibana/blob/master/STYLEGUIDE.mdx), which includes recommendations that can't be linted on.
+We use es-lint rules when possible, but please review our [styleguide](https://github.com/elastic/kibana/blob/main/STYLEGUIDE.mdx), which includes recommendations that can't be linted on.
 
 Es-lint overrides on a per-plugin level are discouraged.
 
@@ -231,7 +231,7 @@ Consider how you want to handle the PR review. Reviewing each PR going into the
 
 **3. Use an example plugin**
 
-If you are building a service for developers, create an [example plugin](https://github.com/elastic/kibana/tree/master/examples) to showcase and test intended usage. This is a great way for reviewers and PMs to play around with a feature through the UI, before the production UI is ready. This can also help developers consuming your services get hands on.
+If you are building a service for developers, create an [example plugin](https://github.com/elastic/kibana/tree/main/examples) to showcase and test intended usage. This is a great way for reviewers and PMs to play around with a feature through the UI, before the production UI is ready. This can also help developers consuming your services get hands on.
 
 ## Embrace the monorepo
 
@@ -241,7 +241,7 @@ When experimenting with code, it's completely fine to create a separate GitHub r
 
 There are some exceptions where a separate repo makes sense. However, they are exceptions to the rule. A separate repo has proven beneficial when there's a dedicated team collaborating on a package which has multiple consumers, for example [EUI](https://github.com/elastic/eui).
 
-It may be tempting to get caught up in the dream of writing the next package which is published to npm and downloaded millions of times a week. Knowing the quality of developers that are working on Kibana, this is a real possibility. However, knowing which packages will see mass adoption is impossible to predict. Instead of jumping directly to writing code in a separate repo and accepting all of the complications that come along with it, prefer keeping code inside the Kibana repo. A [Kibana package](https://github.com/elastic/kibana/tree/master/packages) can be used to publish a package to npm, while still keeping the code inside the Kibana repo. Move code to an external repo only when there is a good reason, for example to enable external contributions.
+It may be tempting to get caught up in the dream of writing the next package which is published to npm and downloaded millions of times a week. Knowing the quality of developers that are working on Kibana, this is a real possibility. However, knowing which packages will see mass adoption is impossible to predict. Instead of jumping directly to writing code in a separate repo and accepting all of the complications that come along with it, prefer keeping code inside the Kibana repo. A [Kibana package](https://github.com/elastic/kibana/tree/main/packages) can be used to publish a package to npm, while still keeping the code inside the Kibana repo. Move code to an external repo only when there is a good reason, for example to enable external contributions.
 
 ## Security best practices