Merge branch '7.x' into backport/7.x/pr-92937

.bazelrc

@@ -16,3 +16,12 @@ build --workspace_status_command="node ./src/dev/bazel_workspace_status.js"
 # build --build_metadata=VISIBILITY=PUBLIC
 build --build_metadata=TEST_GROUPS=//packages
 
+###############################
+# Offline Support             #
+# Turn on these settings with #
+#  --config=offline           #
+###############################
+
+## Reset remote cache and backend support
+build:offline --bes_backend="" --remote_cache=""
+run:offline --bes_backend="" --remote_cache=""

.bazelrc.common

@@ -7,7 +7,9 @@
 
 # Local Cache Settings
 ## Avoid cache results from being corrupt when changing source during build
-common --experimental_guard_against_concurrent_changes
+build --experimental_guard_against_concurrent_changes
+run --experimental_guard_against_concurrent_changes
+test --experimental_guard_against_concurrent_changes
 
 ## Cache action outputs on disk so they persist across output_base and bazel shutdown (eg. changing branches)
 build --disk_cache=~/.bazel-cache/disk-cache

.eslintrc.js

@@ -793,6 +793,22 @@ module.exports = {
       },
     },
 
+    /**
+     * Fleet overrides
+     */
+    {
+      files: ['x-pack/plugins/fleet/**/*.{js,mjs,ts,tsx}'],
+      rules: {
+        'import/order': [
+          'warn',
+          {
+            groups: ['builtin', 'external', 'internal', 'parent'],
+            'newlines-between': 'always-and-inside-groups',
+          },
+        ],
+      },
+    },
+
     /**
      * Security Solution overrides
      */

.yarnrc

@@ -3,3 +3,9 @@ yarn-offline-mirror ".yarn-local-mirror"
 
 # Always look into the cache first before fetching online
 --install.prefer-offline true
+
+# Disable interactive and progress logs as yarn install is now
+# managed by Bazel and we are piping the logs from the underlying
+# process running bazel into the parent one running kbn
+--install.non-interactive true
+--install.no-progress true

BUILD.bazel

@@ -1,3 +1,5 @@
+# Expose those targets as they are required as part of
+# other packages builds and need to be included as inputs
 exports_files(
   [
     "tsconfig.json",

WORKSPACE.bazel

@@ -1,3 +1,68 @@
+# Define the workspace base name and a managed directory by bazel
+# that will hold the node_modules called @npm
 workspace(
-    name = "kibana",
+  name = "kibana",
+  managed_directories = {"@npm": ["node_modules"]},
+)
+
+load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
+
+# Fetch Node.js rules
+http_archive(
+  name = "build_bazel_rules_nodejs",
+  sha256 = "bfacf15161d96a6a39510e7b3d3b522cf61cb8b82a31e79400a84c5abcab5347",
+  urls = ["https://github.com/bazelbuild/rules_nodejs/releases/download/3.2.1/rules_nodejs-3.2.1.tar.gz"],
+)
+
+# Now that we have the rules let's import from them to complete the work
+load("@build_bazel_rules_nodejs//:index.bzl", "check_rules_nodejs_version", "node_repositories", "yarn_install")
+
+# Assure we have at least a given rules_nodejs version
+check_rules_nodejs_version(minimum_version_string = "3.2.1")
+
+# Setup the Node.js toolchain for the architectures we want to support
+#
+# NOTE: darwin-arm64 is not being installed because bazel is not yet available on that architecture.
+# The PR for it was merged and should be available in the next release of bazel and bazelisk. As soon as they have it
+# we can update that rule.
+node_repositories(
+  node_repositories = {
+    "14.16.0-darwin_amd64": ("node-v14.16.0-darwin-x64.tar.gz", "node-v14.16.0-darwin-x64", "14ec767e376d1e2e668f997065926c5c0086ec46516d1d45918af8ae05bd4583"),
+    "14.16.0-linux_arm64": ("node-v14.16.0-linux-arm64.tar.xz", "node-v14.16.0-linux-arm64", "440489a08bfd020e814c9e65017f58d692299ac3f150c8e78d01abb1104c878a"),
+    "14.16.0-linux_s390x": ("node-v14.16.0-linux-s390x.tar.xz", "node-v14.16.0-linux-s390x", "335348e46f45284b6356416ef58f85602d2dee99094588b65900f6c8839df77e"),
+    "14.16.0-linux_amd64": ("node-v14.16.0-linux-x64.tar.xz", "node-v14.16.0-linux-x64", "2e079cf638766fedd720d30ec8ffef5d6ceada4e8b441fc2a093cb9a865f4087"),
+    "14.16.0-windows_amd64": ("node-v14.16.0-win-x64.zip", "node-v14.16.0-win-x64", "716045c2f16ea10ca97bd04cf2e5ef865f9c4d6d677a9bc25e2ea522b594af4f"),
+  },
+  node_version = "14.16.0",
+  node_urls = [
+    "https://nodejs.org/dist/v{version}/{filename}",
+  ],
+  yarn_repositories = {
+    "1.21.1": ("yarn-v1.21.1.tar.gz", "yarn-v1.21.1", "d1d9f4a0f16f5ed484e814afeb98f39b82d4728c6c8beaafb5abc99c02db6674"),
+  },
+  yarn_version = "1.21.1",
+  yarn_urls = [
+    "https://github.com/yarnpkg/yarn/releases/download/v{version}/{filename}",
+  ],
+  package_json = ["//:package.json"],
+)
+
+# Run yarn_install rule to take care of dependencies
+#
+# NOTE: FORCE_COLOR env var forces colors on non tty mode
+yarn_install(
+  name = "npm",
+  environment = {
+    "FORCE_COLOR": "True",
+  },
+  package_json = "//:package.json",
+  yarn_lock = "//:yarn.lock",
+  data = [
+    "//:.yarnrc",
+    "//:preinstall_check.js",
+    "//:node_modules/.yarn-integrity",
+  ],
+  symlink_node_modules = True,
+  quiet = False,
+  frozen_lockfile = False,
 )

dev_docs/kibana_platform_plugin_intro.mdx

@@ -68,7 +68,7 @@ We will continue to focus on adding clarity around these types of services and w
 
 ### Core services
 
-Sometimes referred to just as Core, Core services provide the most basic and fundamental tools neccessary for building a plugin, like creating saved objects,
+Sometimes referred to just as <DocLink id="kibServerAndCoreComponents" text="Core, Core services"/> provide the most basic and fundamental tools neccessary for building a plugin, like creating saved objects,
 routing, application registration, notifications and <DocLink id="kibCoreLogging" text="logging"/>. The Core platform is not a plugin itself, although
 there are some plugins that provide platform functionality. We call these <DocLink id="kibPlatformIntro" section="platform-plugins" text="Platform plugins"/>.
 
@@ -141,4 +141,4 @@ plugins to customize the Kibana experience. Examples of extension points are:
 
 ## Follow up material
 
-Learn how to build your own plugin by following <DocLink id="kibDevTutorialBuildAPlugin" />
+Learn how to build your own plugin by following <DocLink id="kibDevTutorialBuildAPlugin" />.

dev_docs/kibana_server_core_components.mdx

@@ -0,0 +1,30 @@
+---
+id: kibServerAndCoreComponents
+slug: /kibana-dev-docs/core-intro
+title: Core components
+summary: An introduction to the Kibana server and core components.
+date: 2021-02-26
+tags: ['kibana','onboarding', 'dev', 'architecture']
+---
+
+Core is a set of systems (frontend, backend etc.) that Kibana and its plugins are built on top of.
+
+## Integration with the "legacy" Kibana
+
+Most of the existing core functionality is still spread over "legacy" Kibana and it will take some time to upgrade it.
+Kibana is started using existing "legacy" CLI that bootstraps `core` which in turn creates the "legacy" Kibana server.
+At the moment `core` manages HTTP connections, handles TLS configuration and base path proxy. All requests to Kibana server
+will hit HTTP server exposed by the `core` first and it will decide whether request can be solely handled by the new
+platform or request should be proxied to the "legacy" Kibana. This setup allows `core` to gradually introduce any "pre-route"
+processing logic, expose new routes or replace old ones handled by the "legacy" Kibana currently.
+
+Once config has been loaded and some of its parts were validated by the `core` it's passed to the "legacy" Kibana where
+it will be additionally validated so that we can make config validation stricter with the new config validation system.
+Even though the new validation system provided by the `core` is also based on Joi internally it is complemented with custom
+rules tailored to our needs (e.g. `byteSize`, `duration` etc.). That means that config values that were previously accepted
+by the "legacy" Kibana may be rejected by the `core` now.
+
+### Logging
+`core` has its own <DocLink id="kibCoreLogging" text="logging system"/> and will output log records directly (e.g. to file or terminal) when configured. When no specific configuration is provided, logs are forwarded to the "legacy" Kibana so that they look the same as the rest of the
+log records throughout Kibana.
+

docs/developer/getting-started/index.asciidoc

@@ -47,6 +47,23 @@ https://github.com/nodejs/node-gyp#installation[https://github.com/nodejs/node-g
 and follow the guide according your platform.
 ____
 
+In case you don't have an internet connection, the `yarn kbn bootstrap` command will 
+fail. As it is likely you have the required node_modules in the 
+offline mirror, you can try to run the step in offline mode by using:
+
+[source,bash]
+----
+yarn kbn bootstrap --offline
+----
+
+In any other circumstance where you want to force the node_modules install step 
+you can use:
+
+[source,bash]
+----
+yarn kbn bootstrap --force-install
+----
+
 (You can also run `yarn kbn` to see the other available commands. For
 more info about this tool, see
 {kib-repo}tree/{branch}/packages/kbn-pm[{kib-repo}tree/{branch}/packages/kbn-pm].)

docs/development/plugins/data/public/kibana-plugin-plugins-data-public.fieldformats.md

@@ -34,5 +34,6 @@ fieldFormats: {
     UrlFormat: typeof UrlFormat;
     StringFormat: typeof StringFormat;
     TruncateFormat: typeof TruncateFormat;
+    HistogramFormat: typeof HistogramFormat;
 }
 ```

docs/development/plugins/data/server/kibana-plugin-plugins-data-server.fieldformats.md

@@ -23,5 +23,6 @@ fieldFormats: {
     UrlFormat: typeof UrlFormat;
     StringFormat: typeof StringFormat;
     TruncateFormat: typeof TruncateFormat;
+    HistogramFormat: typeof HistogramFormat;
 }
 ```

docs/management/managing-fields.asciidoc

@@ -57,11 +57,17 @@ include::field-formatters/string-formatter.asciidoc[]
 [[field-formatters-numeric]]
 === Numeric field formatters
 
-Numeric fields support the `Url`, `Bytes`, `Duration`, `Number`, `Percentage`, `String`, and `Color` formatters.
+Numeric fields support the `Url`, `Bytes`, `Duration`, `Number`, `Percentage`, `Histogram`, `String`, and `Color` formatters.
 
 The `Bytes`, `Number`, and `Percentage` formatters enable you to choose the display formats of numbers in this field using
 the <<numeral, Elastic numeral pattern>> syntax that {kib} maintains.
 
+The `Histogram` formatter is only used for the {ref}/histogram.html[histogram field type]. When using the `Histogram` formatter,
+you can apply the `Number`, `Bytes`, or `Percentage` format to the aggregated data.
+
+`Number`, and `Percentage` formatters enable you to choose the display formats of numbers in this field using
+the <<numeral, Elastic numeral pattern>> syntax that {kib} maintains.
+
 include::field-formatters/url-formatter.asciidoc[]
 
 include::field-formatters/string-formatter.asciidoc[]

docs/settings/task-manager-settings.asciidoc

@@ -27,6 +27,6 @@ Task Manager runs background tasks by polling for work on an interval.  You can
 
   | `xpack.task_manager.max_workers`
   | The maximum number of tasks that this Kibana instance will run simultaneously.  Defaults to 10.
-
+    Starting in 8.0, it will not be possible to set the value greater than 100.
 
 |===

docs/user/alerting/defining-alerts.asciidoc

@@ -95,6 +95,10 @@ Some cases exist where the variable values will be "escaped", when used in a con
 
 Mustache also supports "triple braces" of the form `{{{variable name}}}`, which indicates no escaping should be done at all.  Care should be used when using this form, as it could end up rendering the variable content in such a way as to make the resulting parameter invalid or formatted incorrectly.
 
+Each alert type defines additional variables as properties of the variable `context`.  For example, if an alert type defines a variable `value`, it can be used in an action parameter as `{{context.value}}`.  
+
+For diagnostic or exploratory purposes, action variables whose values are objects, such as `context`, can be referenced directly as variables.  The resulting value will be a JSON representation of the object.  For example, if an action parameter includes `{{context}}`, it will expand to the JSON representation of all the variables and values provided by the alert type.
+
 You can attach more than one action. Clicking the "Add action" button will prompt you to select another alert type and repeat the above steps again.
 
 [role="screenshot"]

package.json

@@ -58,7 +58,7 @@
     "kbn:watch": "node scripts/kibana --dev --logging.json=false",
     "build:types": "rm -rf ./target/types && tsc --p tsconfig.types.json",
     "docs:acceptApiChanges": "node --max-old-space-size=6144 scripts/check_published_api_changes.js --accept",
-    "kbn:bootstrap": "node scripts/build_ts_refs",
+    "kbn:bootstrap": "node scripts/build_ts_refs --ignore-type-failures",
     "spec_to_console": "node scripts/spec_to_console",
     "storybook": "node scripts/storybook"
   },

packages/BUILD.bazel

@@ -1,4 +1,5 @@
-# Call each package final target
+# Grouping target to call all underlying packages build
+# targets so we can build them all at once
 filegroup(
   name = "build",
   srcs = [],