Merge remote-tracking branch 'upstream/7.x' into backport/7.x/pr-91863

Author: angorayc

.ci/Jenkinsfile_baseline_capture

@@ -3,40 +3,48 @@
 library 'kibana-pipeline-library'
 kibanaLibrary.load()
 
-kibanaPipeline(timeoutMinutes: 120) {
+kibanaPipeline(timeoutMinutes: 210) {
   githubCommitStatus.trackBuild(params.commit, 'kibana-ci-baseline') {
     ciStats.trackBuild {
-      catchError {
-        withEnv([
-          'CI_PARALLEL_PROCESS_NUMBER=1'
-        ]) {
-          parallel([
-            'oss-baseline': {
-              workers.ci(name: 'oss-baseline', size: 'l', ramDisk: true, runErrorReporter: false, bootstrapped: false) {
-                // bootstrap ourselves, but with the env needed to upload the ts refs cache
-                withGcpServiceAccount.fromVaultSecret('secret/kibana-issues/dev/ci-artifacts-key', 'value') {
-                  withEnv([
-                    'BUILD_TS_REFS_CACHE_ENABLE=true',
-                    'BUILD_TS_REFS_CACHE_CAPTURE=true'
-                  ]) {
-                    kibanaPipeline.doSetup()
-                  }
-                }
+      catchErrors {
+        slackNotifications.onFailure(
+          title: "*<${env.BUILD_URL}|[${params.branch}] Baseline Capture Failure>*",
+          message: "[${params.branch}/${params.commit}] Baseline Capture Failure",
+        ) {
+          retryable.enable(2)
 
-                kibanaPipeline.functionalTestProcess('oss-baseline', './test/scripts/jenkins_baseline.sh')()
+          catchErrors {
+            workers.ci(
+              name: 'baseline-worker',
+              size: 'xl',
+              ramDisk: true,
+              runErrorReporter: false,
+              bootstrapped: false
+            ) {
+              withGcpServiceAccount.fromVaultSecret('secret/kibana-issues/dev/ci-artifacts-key', 'value') {
+                withEnv([
+                  'BUILD_TS_REFS_CACHE_ENABLE=true',
+                  'BUILD_TS_REFS_CACHE_CAPTURE=true',
+                  'DISABLE_BOOTSTRAP_VALIDATIONS=true',
+                ]) {
+                  kibanaPipeline.doSetup()
+                }
               }
-            },
-            'xpack-baseline': {
-              workers.ci(name: 'xpack-baseline', size: 'l', ramDisk: true, runErrorReporter: false) {
-                kibanaPipeline.functionalTestProcess('xpack-baseline', './test/scripts/jenkins_xpack_baseline.sh')()
+
+              kibanaPipeline.withCiTaskQueue([parallel: 2]) {
+                catchErrors {
+                  tasks([
+                    kibanaPipeline.functionalTestProcess('oss-baseline', './test/scripts/jenkins_baseline.sh'),
+                    kibanaPipeline.functionalTestProcess('xpack-baseline', './test/scripts/jenkins_xpack_baseline.sh'),
+                  ])
+                }
               }
-            },
-          ])
+            }
+          }
         }
       }
-
-      kibanaPipeline.sendMail()
-      slackNotifications.onFailure()
     }
+
+    kibanaPipeline.sendMail()
   }
 }

.telemetryrc.json

@@ -2,15 +2,6 @@
   {
     "output": "src/plugins/telemetry/schema/oss_plugins.json",
     "root": "src/plugins/",
-    "exclude": [
-      "src/plugins/kibana_react/",
-      "src/plugins/testbed/",
-      "src/plugins/kibana_utils/"
-    ]
-  },
-  {
-    "output": "src/plugins/telemetry/schema/legacy_plugins.json",
-    "root": "src/legacy/server/",
     "exclude": []
   }
 ]

dev_docs/building_blocks.mdx

@@ -0,0 +1,138 @@
+---
+id: kibBuildingBlocks
+slug: /kibana-dev-docs/building-blocks
+title: Building blocks
+summary: Consider these building blocks when developing your plugin.
+date: 2021-02-24
+tags: ['kibana','onboarding', 'dev', 'architecture']
+---
+
+When building a plugin in Kibana, there are a handful of architectural "building blocks" you can use. Some of these building blocks are "higher-level", 
+and some are "lower-level". High-level building blocks come 
+with many built-in capabilities, require less maintenance, and evolve new feature sets over time with little to no
+ impact on consumers. When developers use high-level building blocks, new features are exposed consistently, across all of Kibana, at the same time.
+  On the downside, they are not as flexible as our low-level building blocks. 
+ 
+ Low-level building blocks
+ provide greater flexibility, but require more code to stitch them together into a meaningful UX. This results in higher maintenance cost for consumers and greater UI/UX variability
+ across Kibana.
+
+ For example, if an application is using <DocLink id="kibBuildingBlocks" section="index-patterns" text="Index Patterns"/> and 
+ <DocLink id="kibBuildingBlocks" section="search-source" text="Search Source"/>, 
+ their application would automatically support runtime fields. If the app is instead using the
+ lower-level <DocLink id="kibBuildingBlocks" section="search-strategy" text="Search Strategy"/>, additional work would be required.
+
+Armed with this knowledge, you can choose what works best for your use case!
+
+# Application building blocks
+
+## UI components
+
+The following high-level building blocks can be rendered directly into your application UI.
+
+### Query Bar
+
+The <DocLink id="kibDataPlugin" text="Data plugin"/> provides a high-level Query Bar component that comes with support for Lucene, KQL, Saved Queries, 
+and <DocLink id="kibBuildingBlocks" section="index-patterns" text="Index Patterns"/>.
+
+If you would like to expose the ability to search and filter on Elasticsearch data, the Query Bar provided by the
+<DocLink id="kibDataPlugin" text="Data plugin"/> 
+ is your go-to building block.
+
+**Github labels**: `Team:AppServices`, `Feature:QueryBar`
+
+### Dashboard Embeddable
+
+Add a Dashboard Embeddable directly inside your application to provide users with a set of visualizations and graphs that work seamlessly
+with the <DocLink id="kibBuildingBlocks" section="query-bar" text="Query Bar"/>. Every feature that is added to a registered 
+<DocLink id="kibBuildingBlocks" section="embeddables" text="Embeddable"/> 
+(Lens, Maps, Saved Searches and more) will be available automatically, as well as any
+ <DocLink id="kibBuildingBlocks" section="ui-actions--triggers" text="UI Actions"/> that are
+ added to the Embeddable context menu panel (for example, drilldowns, custom panel time ranges, and "share to" features).
+
+The Dashboard Embeddable is one of the highest-level UI components you can add to your application.
+
+**Github labels**: `Team:Presentation`, `Feature:Dashboard`
+
+### Lens Embeddable
+
+Check out the Lens Embeddable if you wish to show users visualizations based on Elasticsearch data without worrying about query building and chart rendering. It's built on top of the
+ <DocLink id="kibBuildingBlocks" section="expressions" text="Expression language"/>, and integrates with
+  <DocLink id="kibBuildingBlocks" section="index-patterns" text="Index Patterns"/>
+ and <DocLink id="kibBuildingBlocks" section="ui-actions--triggers" text="UI Actions"/>. Using the same configuration, it's also possible to link to
+ a prefilled Lens editor, allowing the user to drill deeper and explore their data.
+
+**Github labels**: `Team:KibanaApp`, `Feature:Lens`
+
+### Map Embeddable
+
+Check out the Map Embeddable if you wish to embed a map in your application.
+
+**Github labels**: `Team:Geo`
+
+## Searching
+
+### Index Patterns
+
+<DocLink id="kibDataPlugin" section="index-patterns-api" text="Index Patterns"/> are a high-level, space-aware abstraction layer that sits 
+above Data Streams and Elasticsearch indices. Index Patterns provide users the 
+ability to define and customize the data they wish to search and filter on, on a per-space basis. For example, users can specify a set of indices, 
+and they can customize the field list with runtime fields, formatting options and custom labels.
+
+Index Patterns are used in many other high-level building blocks so we highly recommend you consider this building block for your search needs.
+
+**Github labels**: `Team:AppServices`, `Feature:Index Patterns`
+
+### Search Source
+
+<DocLink id="kibDataPlugin" section="searchsource" text="Search Source"/> is a high-level search service offered by the
+<DocLink id="kibDataPlugin" section="searchsource" text="Data plugin"/>. It requires an
+<DocLink id="kibBuildingBlocks" section="index-patterns" text="Index Pattern"/>, and abstracts away the raw ES DSL and search endpoint. Internally
+it uses the ES <DocLink id="kibBuildingBlocks" section="search-strategies" text="Search Strategy"/>. Use Search Source if you need to query data 
+from Elasticsearch, and you aren't already using one of the high-level UI Components that handles this internally.
+
+**Github labels**: `Team:AppServices`, `Feature:Search`
+
+### Search Strategies
+
+Search Strategies are a low-level building block that abstracts away search details, like what REST endpoint is being called. The ES Search Strategy 
+is a very lightweight abstraction layer that sits just above querying ES with the elasticsearch-js client. Other search stragies are offered for other 
+languages, like EQL and SQL. These are very low-level building blocks so expect a lot of glue work to make these work with the higher-level abstractions.
+
+**Github labels**: `Team:AppServices`, `Feature:Search`
+
+### Expressions
+
+Expressions are a low-level building block that can be used if you have advanced search needs that requiring piping results into additional functionality, like
+joining and manipulating data. Lens and Canvas are built on top of Expressions. Most developers should be able to use
+ <DocLink id="kibBuildingBlocks" section="lens-embeddable" text="Lens"/> or
+  <DocLink id="kibBuildingBlocks" section="search-source" text="Search Source"/>, rather than need to access the Expression language directly.  
+
+**Github labels**: `Team:AppServices`, `Feature:ExpressionLanguage`
+
+## Saved Objects
+
+<DocLink id="kibDevDocsSavedObjectsIntro" text="Saved Objects" /> should be used if you need to persist application-level information. If you were building a TODO
+application, each TODO item would be a `Saved Object`. Saved objects come pre-wired with support for bulk export/import, security features like space sharing and
+space isolation, and tags.
+
+**Github labels**: `Team:Core`, `Feature:Saved Objects`
+
+# Integration building blocks
+
+Use the following building blocks to create an inter-connected, cross-application, holistic Kibana experience. These building blocks allow you to expose functionality
+ that promotes your own application into other applications, as well as help developers of other applications integrate into your app.
+
+## UI Actions & Triggers
+
+Integrate custom actions into other applications by registering UI Actions attached to existing triggers. For example, the Maps
+application could register a UI Action called "View in Maps" to appear any time the user clicked a geo field to filter on.
+
+**Github labels**: `Team:AppServices`, `Feature:UIActions`
+
+## Embeddables
+
+Embeddables help you integrate your application with the Dashboard application. Register your custom UI Widget as an Embeddable and users will
+be able to add it as a panel on a Dashboard. With a little extra work, it can also be exposed in Canvas workpads. 
+
+**Github labels**: `Team:AppServices`, `Feature:Embeddables`

docs/action-type-template.asciidoc

@@ -0,0 +1,73 @@
+[[<ACTION-TYPE>-action-type]]
+=== <ACTION-TYPE> action
+++++
+<titleabbrev><ACTION-TYPE></titleabbrev>
+++++
+
+Include a short description of the action type.
+
+[float]
+[[<ACTION-TYPE>-connector-configuration]]
+==== Connector configuration
+
+<ACTION-TYPE> connectors have the following configuration properties.
+
+////
+List of user-facing connector configurations. This should align with the fields available in the Create connector flyout form for this action type.
+////
+
+Property1:: A short description of this property.
+Property2:: A short description of this property with format hints. This can be specified in `this specific format`.
+
+[float]
+[[Preconfigured-<ACTION-TYPE>-configuration]]
+==== Preconfigured action type
+
+////
+Example preconfigured format for this action type
+////
+
+[source,text]
+--
+ my-<ACTION-TYPE>:
+   name: preconfigured-<ACTION-TYPE>-action-type
+   actionTypeId: .<ACTION-TYPE>
+   config:
+     property1: value1
+     property2: value2
+   secrets:
+     property3: value3
+--
+
+[float]
+[[<ACTION-TYPE>-connector-config-properties]]
+////
+List of properties from the ConfigSchema and SecretsSchema for this action type.
+////
+Config defines information for the action type.
+
+`property1`:: A short description of this property.
+`property2`:: A short descriptionn of this property.
+
+Secrets defines sensitive information for the action type.
+
+`property3`:: A short descriptionn of this property.
+
+[float]
+[[<ACTION-TYPE>-action-configuration]]
+==== Action configuration
+
+<ACTION-TYPE> actions have the following configuration properties.
+
+////
+List of user-facing action configurations. This should align with the fields available in the Action section of the Create/Update alert flyout.
+////
+
+Property1:: A short description of this property.
+Property2:: A short description of this property with format hints. This can be specified in `this specific format`.
+
+////
+Optional - additional configuration details here
+[[configuring-<ACTION-TYPE>]]
+==== Configure <ACTION-TYPE>
+////

docs/alert-type-template.asciidoc

@@ -0,0 +1,39 @@
+[[alert-type-<ALERT TYPE>]]
+=== <ALERT TYPE>
+
+Include a short description of the alert type.
+
+[float]
+==== Create the alert
+
+Fill in the <<defining-alerts-general-details, alert details>>, then select *<ALERT TYPE>*.
+
+[float]
+==== Define the conditions
+
+Define properties to detect the condition.
+
+////
+Optional, include a screenshot
+[role="screenshot"]
+image::user/alerting/images/alert-types-<ALERT TYPE>-conditions.png[Conditions for <ALERT TYPE> alert type]
+////
+
+Condition1:: This is a condition the user must define.
+Condition2:: This is another condition the user must define.
+
+[float]
+==== Add action variables
+
+<<defining-alerts-actions-details, Add an action>> to run when the alert condition is met. The following variables are specific to the <ALERT TYPE> alert. You can also specify <<defining-alerts-actions-variables, variables common to all alerts>>.
+
+`context.variableA`:: A short description of the context variable defined by the alert type.
+`context.variableB`:: A short description of the context variable defined by the alert type with an example. Example: `this is what variableB outputs`.
+
+////
+Optional, include a step-by-step example for creating this alert 
+[float]
+==== Example
+
+In this section, you will use the {kib} <<add-sample-data, weblog sample dataset>> to setup and tune the conditions on an <ALERT TYPE> alert. For this example, we want to detect when <DESCRIBE THE CONDITIONS>.
+////

docs/developer/plugin-list.asciidoc

@@ -27,6 +27,8 @@ NOTE:
 
 
 |{kib-repo}blob/{branch}/src/plugins/apm_oss/README.asciidoc[apmOss]
+|undefined
+
 
 |{kib-repo}blob/{branch}/src/plugins/bfetch/README.md[bfetch]
 |bfetch allows to batch HTTP requests and streams responses back.

docs/management/advanced-options.asciidoc

@@ -83,6 +83,10 @@ specific dashboard, application, or saved object as they enter each space.
 [[fields-popularlimit]]`fields:popularLimit`::
 The top N most popular fields to show.
 
+[[fileupload-maxfilesize]]`fileUpload:maxFileSize`::
+Sets the file size limit when importing files. The default
+value is `100MB`. The highest supported value for this setting is `1GB`.
+
 [[filtereditor-suggestvalues]]`filterEditor:suggestValues`::
 Set this property to `false` to prevent the filter editor from suggesting values
 for fields.
@@ -258,7 +262,7 @@ Hides the "Time" column in *Discover* and in all saved searches on dashboards.
 Highlights results in *Discover* and saved searches on dashboards. Highlighting
 slows requests when working on big documents.
 
-[[doctable-legacy]]`doc_table:legacy`:: 
+[[doctable-legacy]]`doc_table:legacy`::
 Controls the way the document table looks and works. Set this property to `true` to revert to the legacy implementation.
 
 [[discover-searchFieldsFromSource]]`discover:searchFieldsFromSource`::
@@ -282,10 +286,6 @@ must contain `from` and `to` values (see
 {ref}/common-options.html#date-math[accepted formats]). It is ignored unless
 `ml:anomalyDetection:results:enableTimeDefaults` is enabled.
 
-[[ml-filedatavisualizermaxfilesize]]`ml:fileDataVisualizerMaxFileSize`::
-Sets the file size limit when importing data in the {data-viz}. The default
-value is `100MB`. The highest supported value for this setting is `1GB`.
-
 
 [float]
 [[kibana-notification-settings]]