Merge branch 'main' of github.com:elastic/kibana into security/remove…

…-session-index-template

.buildkite/ftr_configs.yml

@@ -73,6 +73,7 @@ enabled:
   - test/functional/apps/discover/config.ts
   - test/functional/apps/getting_started/config.ts
   - test/functional/apps/home/config.ts
+  - test/functional/apps/kibana_overview/config.ts
   - test/functional/apps/management/config.ts
   - test/functional/apps/saved_objects_management/config.ts
   - test/functional/apps/status_page/config.ts

.buildkite/pipelines/code_coverage/daily.yml

@@ -13,7 +13,7 @@ steps:
       queue: kibana-default
     env:
       FTR_CONFIGS_DEPS: ''
-#      LIMIT_CONFIG_TYPE: 'unit,functional,integration'
+      #      LIMIT_CONFIG_TYPE: 'unit,functional,integration'
       LIMIT_CONFIG_TYPE: 'unit,integration'
       JEST_UNIT_SCRIPT: '.buildkite/scripts/steps/code_coverage/jest.sh'
       JEST_INTEGRATION_SCRIPT: '.buildkite/scripts/steps/code_coverage/jest_integration.sh'
@@ -26,6 +26,6 @@ steps:
     depends_on:
       - jest
       - jest-integration
-#      - ftr-configs
+    #      - ftr-configs
     timeout_in_minutes: 30
     key: ingest

.buildkite/pipelines/performance/daily.yml

@@ -25,6 +25,12 @@ steps:
   #     queue: n2-2
   #   depends_on: tests
 
+  - label: ':chart_with_upwards_trend: Report performance metrics to ci-stats'
+    command: .buildkite/scripts/steps/functional/report_performance_metrics.sh
+    agents:
+      queue: n2-2
+    depends_on: tests
+
   - wait: ~
     continue_on_failure: true
 

.buildkite/scripts/build_kibana.sh

@@ -2,6 +2,8 @@
 
 set -euo pipefail
 
+source .buildkite/scripts/common/util.sh
+
 export KBN_NP_PLUGINS_BUILT=true
 
 echo "--- Build Kibana Distribution"

.buildkite/scripts/steps/code_coverage/ingest.sh

@@ -17,14 +17,16 @@ export HOST_FROM_VAULT
 TIME_STAMP=$(date +"%Y-%m-%dT%H:%M:00Z")
 export TIME_STAMP
 
-echo "--- Download previous git sha"
-.buildkite/scripts/steps/code_coverage/reporting/downloadPrevSha.sh
-PREVIOUS_SHA=$(cat downloaded_previous.txt)
+.buildkite/scripts/bootstrap.sh
 
-echo "--- Upload new git sha"
-.buildkite/scripts/steps/code_coverage/reporting/uploadPrevSha.sh
+revolveBuildHashes() {
+  echo "--- Download previous git sha"
+  .buildkite/scripts/steps/code_coverage/reporting/downloadPrevSha.sh
+  PREVIOUS_SHA=$(cat downloaded_previous.txt)
 
-.buildkite/scripts/bootstrap.sh
+  echo "--- Upload new git sha"
+  .buildkite/scripts/steps/code_coverage/reporting/uploadPrevSha.sh
+}
 
 collectRan() {
   buildkite-agent artifact download target/ran_files/* .
@@ -59,9 +61,9 @@ archiveReports() {
   local xs=("$@")
   for x in "${xs[@]}"; do
     echo "### Collect and Upload for: ${x}"
-#    fileHeads "target/file-heads-archive-reports-for-${x}.txt" "target/kibana-coverage/${x}"
-#    dirListing "target/dir-listing-${x}-combined-during-archiveReports.txt" target/kibana-coverage/${x}-combined
-#    dirListing "target/dir-listing-${x}-during-archiveReports.txt" target/kibana-coverage/${x}
+    #    fileHeads "target/file-heads-archive-reports-for-${x}.txt" "target/kibana-coverage/${x}"
+    #    dirListing "target/dir-listing-${x}-combined-during-archiveReports.txt" target/kibana-coverage/${x}-combined
+    #    dirListing "target/dir-listing-${x}-during-archiveReports.txt" target/kibana-coverage/${x}
     collectAndUpload "target/kibana-coverage/${x}/kibana-${x}-coverage.tar.gz" "target/kibana-coverage/${x}-combined"
   done
 }
@@ -86,25 +88,53 @@ mergeAll() {
   done
 }
 
+annotateForStaticSite() {
+  local xs=("$@")
+  local markdownLinks=()
+
+  OLDIFS="${IFS}"
+  IFS=$'\n'
+
+  for x in "${xs[@]}"; do
+    markdownLinks+=(" - [$x](https://kibana-coverage.elastic.dev/${TIME_STAMP}/${x}-combined/index.html)")
+  done
+
+  content=$(
+    cat <<-EOF
+### Browse the Code Coverage Static Site
+
+_Links are pinned to the current build number._
+
+${markdownLinks[*]}
+EOF
+  )
+
+  IFS="${OLDIFS}"
+
+  buildkite-agent annotate --style "info" --context 'ctx-coverage-static-site' "${content}"
+}
+
 modularize() {
   collectRan
   if [ -d target/ran_files ]; then
+    revolveBuildHashes
     uniqueifyRanConfigs "${ran[@]}"
     fetchArtifacts "${uniqRanConfigs[@]}"
     mergeAll "${uniqRanConfigs[@]}"
     archiveReports "${uniqRanConfigs[@]}"
     .buildkite/scripts/steps/code_coverage/reporting/prokLinks.sh "${uniqRanConfigs[@]}"
     .buildkite/scripts/steps/code_coverage/reporting/uploadStaticSite.sh "${uniqRanConfigs[@]}"
+    annotateForStaticSite "${uniqRanConfigs[@]}"
     .buildkite/scripts/steps/code_coverage/reporting/collectVcsInfo.sh
     source .buildkite/scripts/steps/code_coverage/reporting/ingestData.sh 'elastic+kibana+code-coverage' \
       "${BUILDKITE_BUILD_NUMBER}" "${BUILDKITE_BUILD_URL}" "${PREVIOUS_SHA}" \
       'src/dev/code_coverage/ingest_coverage/team_assignment/team_assignments.txt'
     ingestModular "${uniqRanConfigs[@]}"
+    annotateForKibanaLinks
   else
     echo "--- Found zero configs that ran, cancelling ingestion."
     exit 11
   fi
 }
 
 modularize
-echo "### unique ran configs: ${uniqRanConfigs[*]}"

.buildkite/scripts/steps/code_coverage/reporting/ingestData.sh

@@ -29,6 +29,23 @@ echo "### debug TEAM_ASSIGN_PATH: ${TEAM_ASSIGN_PATH}"
 BUFFER_SIZE=500
 export BUFFER_SIZE
 
+annotateForKibanaLinks() {
+  local currentBuildNumber="$BUILDKITE_BUILD_NUMBER"
+  local coverageUrl="https://kibana-stats.elastic.dev/app/discover#/?_g=(filters:!(),query:(language:kuery,query:''),refreshInterval:(pause:!t,value:0),time:(from:now-7d,to:now))&_a=(columns:!(),filters:!(),hideChart:!f,index:'64419790-4218-11ea-b2d8-81bcbf78dfcb',interval:auto,query:(language:kuery,query:'BUILD_ID%20:%20${currentBuildNumber}'),sort:!(!('@timestamp',desc)))"
+  local totalCoverageUrl="https://kibana-stats.elastic.dev/app/discover#/?_g=(filters:!(),query:(language:kuery,query:''),refreshInterval:(pause:!t,value:0),time:(from:now-7d,to:now))&_a=(columns:!(),filters:!(),hideChart:!f,index:d78f9120-4218-11ea-b2d8-81bcbf78dfcb,interval:auto,query:(language:kuery,query:'BUILD_ID%20:%20${currentBuildNumber}'),sort:!(!('@timestamp',desc)))"
+
+  cat <<EOF | buildkite-agent annotate --style "info" --context 'ctx-kibana-links'
+### Browse the following url(s) to visually verify in Kibana
+
+_Links are pinned to the current build number._
+
+  - [Code Coverage]($coverageUrl)
+  - [Total Code Coverage]($totalCoverageUrl)
+
+EOF
+
+}
+
 ingestModular() {
   local xs=("$@")
 

.buildkite/scripts/steps/functional/report_performance_metrics.sh

@@ -0,0 +1,21 @@
+#!/usr/bin/env bash
+
+set -euo pipefail
+
+source .buildkite/scripts/common/util.sh
+
+# TODO: Add new user and change lines accordingly
+USER_FROM_VAULT="$(retry 5 5 vault read -field=username secret/kibana-issues/dev/ci_stats_performance_metrics)"
+PASS_FROM_VAULT="$(retry 5 5 vault read -field=password secret/kibana-issues/dev/ci_stats_performance_metrics)"
+APM_SERVER_URL="https://kibana-ops-e2e-perf.es.us-central1.gcp.cloud.es.io:9243/internal/apm"
+BUILD_ID=${BUILDKITE_BUILD_ID}
+
+.buildkite/scripts/bootstrap.sh
+
+echo "--- Extract APM metrics & report them to ci-stats"
+
+node scripts/report_performance_metrics \
+    --buildId "${BUILD_ID}" \
+    --apm-url "${APM_SERVER_URL}" \
+    --apm-username "${USER_FROM_VAULT}" \
+    --apm-password "${PASS_FROM_VAULT}"

.github/CODEOWNERS

@@ -202,6 +202,7 @@
 /x-pack/test/functional/apps/transform/ @elastic/ml-ui
 /x-pack/test/functional/services/transform/ @elastic/ml-ui
 /x-pack/test/functional_basic/apps/transform/ @elastic/ml-ui
+/x-pack/packages/ml/ @elastic/ml-ui
 /packages/kbn-aiops-utils @elastic/ml-ui
 /examples/response_stream/ @elastic/ml-ui
 

.i18nrc.json

@@ -7,7 +7,7 @@
     "bfetch": "src/plugins/bfetch",
     "charts": "src/plugins/charts",
     "console": "src/plugins/console",
-    "core": "src/core",
+    "core": ["src/core", "packages/core/i18n/core-i18n-browser-internal"],
     "customIntegrations": "src/plugins/custom_integrations",
     "dashboard": "src/plugins/dashboard",
     "controls": "src/plugins/controls",

FAQ.md

@@ -6,7 +6,7 @@
 **Q:** Where do I go for support?
 **A:** Please join us at [discuss.elastic.co](https://discuss.elastic.co) with questions. Your problem might be a bug, but it might just be a misunderstanding, or a feature we could improve. We're also available on Freenode in #kibana
 
-**Q:** Ok, we talked about it and its definitely a bug
+**Q:** Ok, we talked about it, and it's definitely a bug
 **A:** Doh, ok, let's get that fixed. File an issue on [github.com/elastic/kibana](https://github.com/elastic/kibana). I'd recommend reading the beginning of the CONTRIBUTING.md, just so you know how we'll handle the issue.
 
 ### Kibana 3 Migration

STYLEGUIDE.mdx

@@ -38,18 +38,18 @@ and some JavaScript code (check `.eslintrc.js`) is using Prettier to format code
 can run `node scripts/eslint --fix` to fix linting issues and apply Prettier formatting.
 We recommend you to enable running ESLint via your IDE.
 
-Whenever possible we are trying to use Prettier and linting over written style guide rules.
+Whenever possible we are trying to use Prettier and linting, instead of maintaining a set of written style guide rules.
 Consider every linting rule and every Prettier rule to be also part of our style guide
 and disable them only in exceptional cases and ideally leave a comment why they are
 disabled at that specific place.
 
 ## HTML
 
-This part contains style guide rules around general (framework agnostic) HTML usage.
+This part contains style guide rules around general (framework-agnostic) HTML usage.
 
 ### Camel case `id` and `data-test-subj`
 
-Use camel case for the values of attributes such as `id` and `data-test-subj` selectors.
+Use camel case for the values of attributes such as `id` and `data-test-subj` selectors:
 
 ```html
 <button id="veryImportantButton" data-test-subj="clickMeButton">Click me</button>
@@ -73,8 +73,8 @@ buttons.map(btn => (
 
 It's important that when you write CSS/SASS selectors using classes, IDs, and attributes
 (keeping in mind that we should _never_ use IDs and attributes in our selectors), that the
-capitalization in the CSS matches that used in the HTML. HTML and CSS follow different case sensitivity rules, and we can avoid subtle gotchas by ensuring we use the
-same capitalization in both of them.
+capitalization in the CSS matches that used in the HTML. HTML and CSS follow different case sensitivity rules,
+and we can avoid subtle gotchas by ensuring we use the same capitalization in both of them.
 
 ### How to generate ids?
 
@@ -143,7 +143,8 @@ API routes must start with the `/api/` path segment, and should be followed by t
 
 ### snake_case
 
-Kibana uses `snake_case` for the entire API, just like Elasticsearch. All urls, paths, query string parameters, values, and bodies should be `snake_case` formatted.
+Kibana uses `snake_case` for the entire API, just like Elasticsearch. All urls, paths, query string parameters,
+values, and bodies should be `snake_case` formatted:
 
 _Right:_
 
@@ -202,7 +203,7 @@ function addBar(foos, foo) {
 
 Since TypeScript 3.0 and the introduction of the
 [`unknown` type](https://mariusschulz.com/blog/the-unknown-type-in-typescript) there are rarely any
-reasons to use `any` as a type. Nearly all places of former `any` usage can be replace by either a
+reasons to use `any` as a type. Nearly all places of former `any` usage can be replaced by either a
 generic or `unknown` (in cases the type is really not known).
 
 You should always prefer using those mechanisms over using `any`, since they are stricter typed and
@@ -215,16 +216,16 @@ linting rule for your plugin via the [`.eslintrc.js`](https://github.com/elastic
 ### Avoid non-null assertions
 
 You should try avoiding non-null assertions (`!.`) wherever possible. By using them you tell
-TypeScript, that something is not null even though by it’s type it could be. Usage of non-null
-assertions is most often a side-effect of you actually checked that the variable is not `null`
-but TypeScript doesn’t correctly carry on that information till the usage of the variable.
+TypeScript that something is not `null`, even though by its type it could be. Usage of non-null
+assertions is most often a side effect of you actually checked that the variable is not `null`
+but TypeScript doesn't correctly carry on that information till the usage of the variable.
 
 In most cases it’s possible to replace the non-null assertion by structuring your code/checks slightly different
 or using [user defined type guards](https://www.typescriptlang.org/docs/handbook/advanced-types.html#user-defined-type-guards)
 to properly tell TypeScript what type a variable has.
 
 Using non-null assertion increases the risk for future bugs. In case the condition under which we assumed that the
-variable can’t be null has changed (potentially even due to changes in compeltely different files), the non-null
+variable can’t be `null` has changed (potentially even due to changes in completely different files), the non-null
 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
@@ -266,7 +267,7 @@ function doStuff(val) {
 
 ### Use object destructuring
 
-This helps avoid temporary references and helps prevent typo-related bugs.
+This helps avoid temporary references and helps prevent typo-related bugs:
 
 ```js
 // best
@@ -307,8 +308,8 @@ const second = arr[1];
 ### Magic numbers/strings
 
 These are numbers (or other values) simply used in line in your code. _Do not
-use these_, give them a variable name so they can be understood and changed
-easily.
+use these_, give them a variable name, so they can be understood and changed
+easily:
 
 ```js
 // good
@@ -378,7 +379,9 @@ import inSibling from '../foo/child';
 
 #### Avoid export \* in top level index.ts files
 
-The exports in `common/index.ts`, `public/index.ts` and `server/index.ts` dictate a plugin's public API. The public API should be carefully controlled, and using `export *` makes it very easy for a developer working on internal changes to export a new public API unintentionally.
+The exports in `common/index.ts`, `public/index.ts` and `server/index.ts` dictate a plugin's public API.
+The public API should be carefully controlled, and using `export *` makes it very easy for a developer
+working on internal changes to export a new public API unintentionally:
 
 ```js
 // good
@@ -399,7 +402,7 @@ by other modules. Even things as simple as a single value should be a module.
 
 And _never_ use multiple ternaries together, because they make it more
 difficult to reason about how different values flow through the conditions
-involved. Instead, structure the logic for maximum readability.
+involved. Instead, structure the logic for maximum readability:
 
 ```js
 // good, a situation where only 1 ternary is needed
@@ -466,7 +469,7 @@ perfect vision and limit yourself to ~15 lines of code per function.
 
 ### Use "rest" syntax rather than built-in `arguments`
 
-For expressiveness sake, and so you can be mix dynamic and explicit arguments.
+For the sake of expressiveness, and so you can be mix dynamic and explicit arguments:
 
 ```js
 // good
@@ -483,7 +486,7 @@ function something(foo) {
 
 ### Default argument syntax
 
-Always use the default argument syntax for optional arguments.
+Always use the default argument syntax for optional arguments:
 
 ```js
 // good
@@ -500,7 +503,7 @@ function foo(options) {
 }
 ```
 
-And put your optional arguments at the end.
+And put your optional arguments at the end:
 
 ```js
 // good
@@ -518,7 +521,7 @@ function foo(options = {}, bar) {
 
 For trivial examples (like the one that follows), thunks will seem like
 overkill, but they encourage isolating the implementation details of a closure
-from the business logic of the calling code.
+from the business logic of the calling code:
 
 ```js
 // good
@@ -621,9 +624,13 @@ by your code until the circular dependencies on these have been solved.
 
 ## SASS files
 
-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).
+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_v8light.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
@@ -656,11 +663,12 @@ The following style guide rules are specific for working with the React framewor
 
 ### Prefer reactDirective over react-component
 
-When using `ngReact` to embed your react components inside Angular HTML, prefer the
+When using `ngReact` to embed your React components inside Angular HTML, prefer the
 `reactDirective` service over the `react-component` directive.
 You can read more about these two ngReact methods [here](https://github.com/ngReact/ngReact#features).
 
-Using `react-component` means adding a bunch of components into angular, while `reactDirective` keeps them isolated, and is also a more succinct syntax.
+Using `react-component` means adding a bunch of components into angular, while `reactDirective` keeps them isolated,
+and is also a more succinct syntax:
 
 **Good:**