Merge branch '90445-no-integration-changes-for-managed-policies' of g…

…ithub.com:jfsiii/kibana into 90445-no-integration-changes-for-managed-policies

.ci/es-snapshots/Jenkinsfile_verify_es

@@ -29,7 +29,6 @@ kibanaPipeline(timeoutMinutes: 150) {
       withEnv(["ES_SNAPSHOT_MANIFEST=${SNAPSHOT_MANIFEST}"]) {
         parallel([
           'kibana-intake-agent': workers.intake('kibana-intake', './test/scripts/jenkins_unit.sh'),
-          'x-pack-intake-agent': workers.intake('x-pack-intake', './test/scripts/jenkins_xpack.sh'),
           'kibana-oss-agent': workers.functional('kibana-oss-tests', { kibanaPipeline.buildOss() }, [
             'oss-ciGroup1': kibanaPipeline.ossCiGroupProcess(1),
             'oss-ciGroup2': kibanaPipeline.ossCiGroupProcess(2),

.ci/jobs.yml

@@ -2,7 +2,6 @@
 
 JOB:
   - kibana-intake
-  - x-pack-intake
   - kibana-firefoxSmoke
   - kibana-ciGroup1
   - kibana-ciGroup2

.eslintrc.js

@@ -1119,6 +1119,39 @@ module.exports = {
       // All files
       files: ['x-pack/plugins/enterprise_search/**/*.{ts,tsx}'],
       rules: {
+        'import/order': [
+          'error',
+          {
+            groups: ['unknown', ['builtin', 'external'], 'internal', 'parent', 'sibling', 'index'],
+            pathGroups: [
+              {
+                pattern:
+                  '{../../../../../../,../../../../../,../../../../,../../../,../../,../}{common/,*}__mocks__{*,/**}',
+                group: 'unknown',
+              },
+              {
+                pattern: '{**,.}/*.mock',
+                group: 'unknown',
+              },
+              {
+                pattern: 'react*',
+                group: 'external',
+                position: 'before',
+              },
+              {
+                pattern: '{@elastic/**,@kbn/**,src/**}',
+                group: 'internal',
+              },
+            ],
+            pathGroupsExcludedImportTypes: [],
+            alphabetize: {
+              order: 'asc',
+              caseInsensitive: true,
+            },
+            'newlines-between': 'always-and-inside-groups',
+          },
+        ],
+        'import/newline-after-import': 'error',
         'react-hooks/exhaustive-deps': 'off',
         'react/jsx-boolean-value': ['error', 'never'],
       },

.github/CODEOWNERS

@@ -26,6 +26,7 @@
 /src/plugins/vis_type_xy/ @elastic/kibana-app
 /src/plugins/visualize/ @elastic/kibana-app
 /src/plugins/visualizations/ @elastic/kibana-app
+/packages/kbn-tinymath/ @elastic/kibana-app
 
 # Application Services
 /examples/bfetch_explorer/ @elastic/kibana-app-services

dev_docs/tutorials/building_a_plugin.mdx

@@ -0,0 +1,226 @@
+---
+id: kibDevTutorialBuildAPlugin
+slug: /kibana-dev-docs/tutorials/build-a-plugin
+title: Kibana plugin tutorial
+summary: Anatomy of a Kibana plugin and how to build one
+date: 2021-02-05
+tags: ['kibana','onboarding', 'dev', 'tutorials']
+---
+
+Prereading material:
+
+- <DocLink id="kibPlatformIntro" />
+
+## The anatomy of a plugin
+
+Plugins are defined as classes and present themselves to Kibana through a simple wrapper function. A plugin can have browser-side code, server-side code,
+or both. There is no architectural difference between a plugin in the browser and a plugin on the server. In both places, you describe your plugin similarly, 
+and you interact with Core and other plugins in the same way.
+
+The basic file structure of a Kibana plugin named demo that has both client-side and server-side code would be:
+
+```
+plugins/
+  demo
+    kibana.json [1]
+    public
+      index.ts  [2]
+      plugin.ts [3]
+    server
+      index.ts  [4]
+      plugin.ts [5]
+    common
+      index.ts  [6]
+```
+
+### [1] kibana.json 
+
+`kibana.json` is a static manifest file that is used to identify the plugin and to specify if this plugin has server-side code, browser-side code, or both:
+
+```
+{
+  "id": "demo",
+  "version": "kibana",
+  "server": true,
+  "ui": true
+}
+```
+
+### [2] public/index.ts
+
+`public/index.ts` is the entry point into the client-side code of this plugin. It must export a function named plugin, which will receive a standard set of
+ core capabilities as an argument. It should return an instance of its plugin class for Kibana to load.
+
+```
+import type { PluginInitializerContext } from 'kibana/server';
+import { DemoPlugin } from './plugin';
+
+export function plugin(initializerContext: PluginInitializerContext) {
+  return new DemoPlugin(initializerContext);
+}
+```
+
+### [3] public/plugin.ts
+
+`public/plugin.ts` is the client-side plugin definition itself. Technically speaking, it does not need to be a class or even a separate file from the entry
+ point, but all plugins at Elastic should be consistent in this way.
+
+
+ ```ts
+import type { Plugin, PluginInitializerContext, CoreSetup, CoreStart } from 'kibana/server';
+
+export class DemoPlugin implements Plugin {
+  constructor(initializerContext: PluginInitializerContext) {}
+
+  public setup(core: CoreSetup) {
+    // called when plugin is setting up during Kibana's startup sequence
+  }
+
+  public start(core: CoreStart) {
+    // called after all plugins are set up
+  }
+
+  public stop() {
+    // called when plugin is torn down during Kibana's shutdown sequence
+  }
+}
+ ```
+
+
+### [4] server/index.ts 
+
+`server/index.ts` is the entry-point into the server-side code of this plugin. It is identical in almost every way to the client-side entry-point:
+
+### [5] server/plugin.ts
+
+`server/plugin.ts` is the server-side plugin definition. The shape of this plugin is the same as it’s client-side counter-part:
+
+```ts
+import type { Plugin, PluginInitializerContext, CoreSetup, CoreStart } from 'kibana/server';
+
+export class DemoPlugin implements Plugin {
+  constructor(initializerContext: PluginInitializerContext) {}
+
+  public setup(core: CoreSetup) {
+    // called when plugin is setting up during Kibana's startup sequence
+  }
+
+  public start(core: CoreStart) {
+    // called after all plugins are set up
+  }
+
+  public stop() {
+    // called when plugin is torn down during Kibana's shutdown sequence
+  }
+}
+```
+
+Kibana does not impose any technical restrictions on how the the internals of a plugin are architected, though there are certain 
+considerations related to how plugins integrate with core APIs and APIs exposed by other plugins that may greatly impact how they are built.
+
+### [6] common/index.ts
+
+`common/index.ts` is the entry-point into code that can be used both server-side or client side.
+
+## How plugin's interact with each other, and Core
+
+The lifecycle-specific contracts exposed by core services are always passed as the first argument to the equivalent lifecycle function in a plugin. 
+For example, the core http service exposes a function createRouter to all plugin setup functions. To use this function to register an HTTP route handler, 
+a plugin just accesses it off of the first argument:
+
+```ts
+import type { CoreSetup } from 'kibana/server';
+
+export class DemoPlugin {
+  public setup(core: CoreSetup) {
+    const router = core.http.createRouter();
+    // handler is called when '/path' resource is requested with `GET` method
+    router.get({ path: '/path', validate: false }, (context, req, res) => res.ok({ content: 'ok' }));
+  }
+}
+```
+
+Unlike core, capabilities exposed by plugins are not automatically injected into all plugins.
+Instead, if a plugin wishes to use the public interface provided by another plugin, it must first declare that plugin as a
+ dependency in it’s kibana.json manifest file.
+
+** foobar plugin.ts: **
+
+```
+import type { Plugin } from 'kibana/server';
+export interface FoobarPluginSetup { [1]
+  getFoo(): string;
+}
+
+export interface FoobarPluginStart { [1]
+  getBar(): string;
+}
+
+export class MyPlugin implements Plugin<FoobarPluginSetup, FoobarPluginStart> {
+  public setup(): FoobarPluginSetup {
+    return {
+      getFoo() {
+        return 'foo';
+      },
+    };
+  }
+
+  public start(): FoobarPluginStart {
+    return {
+      getBar() {
+        return 'bar';
+      },
+    };
+  }
+}
+```
+[1]  We highly encourage plugin authors to explicitly declare public interfaces for their plugins.
+
+
+** demo kibana.json**
+
+```
+{
+  "id": "demo",
+  "requiredPlugins": ["foobar"],
+  "server": true,
+  "ui": true
+}
+```
+
+With that specified in the plugin manifest, the appropriate interfaces are then available via the second argument of setup and/or start:
+
+```ts
+import type { CoreSetup, CoreStart } from 'kibana/server';
+import type { FoobarPluginSetup, FoobarPluginStart } from '../../foobar/server';
+
+interface DemoSetupPlugins {  [1]
+  foobar: FoobarPluginSetup;
+}
+
+interface DemoStartPlugins {
+  foobar: FoobarPluginStart;
+}
+
+export class DemoPlugin {
+  public setup(core: CoreSetup, plugins: DemoSetupPlugins) { [2]
+    const { foobar } = plugins;
+    foobar.getFoo(); // 'foo'
+    foobar.getBar(); // throws because getBar does not exist
+  }
+
+  public start(core: CoreStart, plugins: DemoStartPlugins) { [3]
+    const { foobar } = plugins;
+    foobar.getFoo(); // throws because getFoo does not exist
+    foobar.getBar(); // 'bar'
+  }
+
+  public stop() {}
+}
+```
+
+[1] The interface for plugin’s dependencies must be manually composed. You can do this by importing the appropriate type from the plugin and constructing an interface where the property name is the plugin’s ID.
+
+[2] These manually constructed types should then be used to specify the type of the second argument to the plugin.
+
+[3] Notice that the type for the setup and start lifecycles are different. Plugin lifecycle functions can only access the APIs that are exposed during that lifecycle.

docs/developer/contributing/development-ci-metrics.asciidoc

@@ -121,13 +121,20 @@ Changes to the {kib-repo}blob/{branch}/packages/kbn-optimizer/limits.yml[`limits
 [[ci-metric-validating-limits]]
 === Validating `page load bundle size` limits
 
-Once you've fixed any issues discovered while diagnosing overages you probably should just push the changes to your PR and let CI validate them.
+While you're trying to track down changes which will improve the bundle size, try running the following command locally:
 
-If you have a pretty powerful dev machine, or the necessary patience/determination, you can validate the limits locally by running the following command:
+[source,shell]
+-----------
+node scripts/build_kibana_platform_plugins --dist --watch --focus {pluginId}
+-----------
+
+This will build the front-end bundles for your plugin and only the plugins your plugin depends on. Whenever you make changes the bundles are rebuilt and you can inspect the metrics of that build in the `target/public/metrics.json` file within your plugin. This file will be updated as you save changes to the source and should be helpful to determine if your changes are lowering the `page load asset size` enough.
+
+If you only want to run the build once you can run:
 
 [source,shell]
 -----------
-node scripts/build_kibana_platform_plugins --validate-limits
+node scripts/build_kibana_platform_plugins --validate-limits --focus {pluginId}
 -----------
 
 This command needs to apply production optimizations to get the right sizes, which means that the optimizer will take significantly longer to run and on most developmer machines will consume all of your machines resources for 20 minutes or more. If you'd like to multi-task while this is running you might need to limit the number of workers using the `--max-workers` flag.

docs/user/alerting/alert-types.asciidoc

@@ -130,12 +130,13 @@ image::images/alert-types-es-query-select.png[Choosing an ES query alert type]
 [float]
 ==== Defining the conditions
 
-The ES query alert has 4 clauses that define the condition to detect.
+The ES query alert has 5 clauses that define the condition to detect.
 
 [role="screenshot"]
 image::images/alert-types-es-query-conditions.png[Four clauses define the condition to detect]
 
 Index:: This clause requires an *index or index pattern* and a *time field* that will be used for the *time window*.
+Size:: This clause specifies the number of documents to pass to the configured actions when the the threshold condition is met.
 ES query:: This clause specifies the ES DSL query to execute. The number of documents that match this query will be evaulated against the threshold
 condition. Aggregations are not supported at this time. 
 Threshold:: This clause defines a threshold value and a comparison operator  (`is above`, `is above or equals`, `is below`, `is below or equals`, or `is between`). The number of documents that match the specified query is compared to this threshold.

jest.config.integration.js

@@ -17,12 +17,15 @@ module.exports = {
   testPathIgnorePatterns: preset.testPathIgnorePatterns.filter(
     (pattern) => !pattern.includes('integration_tests')
   ),
+  setupFilesAfterEnv: ['<rootDir>/packages/kbn-test/target/jest/setup/after_env.integration.js'],
   reporters: [
     'default',
     [
       '<rootDir>/packages/kbn-test/target/jest/junit_reporter',
       { reportName: 'Jest Integration Tests' },
     ],
   ],
-  setupFilesAfterEnv: ['<rootDir>/packages/kbn-test/target/jest/setup/after_env.integration.js'],
+  coverageReporters: !!process.env.CI
+    ? [['json', { file: 'jest-integration.json' }]]
+    : ['html', 'text'],
 };

jest.config.js

@@ -7,6 +7,14 @@
  */
 
 module.exports = {
+  preset: '@kbn/test',
   rootDir: '.',
-  projects: [...require('./jest.config.oss').projects, ...require('./x-pack/jest.config').projects],
+  projects: [
+    '<rootDir>/packages/*/jest.config.js',
+    '<rootDir>/src/*/jest.config.js',
+    '<rootDir>/src/legacy/*/jest.config.js',
+    '<rootDir>/src/plugins/*/jest.config.js',
+    '<rootDir>/test/*/jest.config.js',
+    '<rootDir>/x-pack/plugins/*/jest.config.js',
+  ],
 };

package.json

@@ -97,7 +97,7 @@
     "@babel/runtime": "^7.12.5",
     "@elastic/datemath": "link:packages/elastic-datemath",
     "@elastic/elasticsearch": "npm:@elastic/elasticsearch-canary@^8.0.0-canary",
-    "@elastic/ems-client": "7.11.0",
+    "@elastic/ems-client": "7.12.0",
     "@elastic/eui": "31.4.0",
     "@elastic/filesaver": "1.1.2",
     "@elastic/good": "^9.0.1-kibana3",