## Summary
The `/packages` folder at the root of the Kibana repository used to
contain a lot of packages.
In the context of SKA, they have been gradually moved to various
locations:
* `src/platform/packages`
* `x-pack/platform/packages`
* `src/core/packages`
Currently, only `devOnly: true` packages are left in this folder. This
comprises libraries for CLI scripts as well as testing utilities.
With this PR, we are moving ~half of these packages under
`src/platform/packages/(private|shared)/`.
In particular, we are moving those packages that are being used from
platform and/or solutions.
Since they are `"devOnly": true`, this means they are ONLY used from
tests, cypress tests, storybook configs, ./scripts/ folders inside some
modules, or other non-prod-time logic. Nonetheless, they are effectively
referenced from platform and/or solutions code, hence I decided they
should be placed under `platform` folders.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Extends the Observability AI Assistant's evaluation framework to create
the first set of tests aimed at evaluating the performance of the
Investigation App's AI root cause analysis integration.
To execute tests, please consult the
[README](https://github.com/elastic/kibana/pull/204634/files#diff-4823a154e593051126d3d5822c88d72e89d07f41b8c07a5a69d18281c50b09adR1).
Note the prerequisites and the Kibana & Elasticsearch configuration.
Further evolution
--
This PR is the first MVP of the evaluation framework. A (somewhat light)
[meta issue](https://github.com/elastic/kibana/issues/205670) exists for
our continued work on this project, and will be added to over time.
Test data and fixture architecture
--
Logs, metrics, and traces are indexed to
[edge-rca](https://studious-disco-k66oojq.pages.github.io/edge-rca/).
Observability engineers can [create an oblt-cli
cluster](https://studious-disco-k66oojq.pages.github.io/user-guide/cluster-create-ccs/)
configured for cross cluster search against edge-rca as the remote
cluster.
When creating new testing fixtures, engineers will utilize their
oblt-cli cluster to create rules against the remote cluster data. Once
alerts are triggered in a failure scenario, the engineer can choose to
archive the alert data to utilize as a test fixture.
Test fixtures are added to the `investigate_app/scripts/load/fixtures`
directory for use in tests.
When execute tests, the fixtures are loaded into the engineer's oblt-cli
cluster, configured for cross cluster search against edge-rca. The local
alert fixture and the remote demo data are utilized together to replay
root cause analysis and execute the test evaluations.
Implementation
--
Creates a new directory `scripts`, to house scripts related to setting
up and running these tests. Here's what each directory does:
## scripts/evaluate
1. Extends the evaluation script from
`observability_ai_assistant_app/scripts/evaluation` by creating a
[custom Kibana
client](https://github.com/elastic/kibana/pull/204634/files#diff-ae05b2a20168ea08f452297fc1bd59310c69ac3ea4651da1f65cd9fa93bb8fe9R1)
with RCA specific methods. The custom client is [passed to the
Observability AI Assistant's
`runEvaluations`](https://github.com/elastic/kibana/pull/204634/files#diff-0f2d3662c01df8fbe7d1f19704fa071cbd6232fb5f732b313e8ba99012925d0bR14)
script an[d invoked instead of the default Kibana
Client](https://github.com/elastic/kibana/pull/204634/files#diff-98509a357e86ea5c5931b1b46abc72f76e5304439430358eee845f9ad57f63f1R54).
2. Defines a single, MVP test in `index.spec.ts`. This test find a
specific alert fixture designated for that test, creates an
investigation for that alert with a specified time range, and calls the
root cause analysis api. Once the report is received back from the api,
a prompt is created for the evaluation framework with details of the
report. The evaluation framework then judges how well the root cause
analysis api performed against specified criteria.
## scripts/archive
1. Utilized when creating new test fixtures, this script will easily
archive observability alerts data for use as a fixture in a feature test
## scripts/load
1. Loads created testing fixtures before running the test.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Dario Gieselaar <d.gieselaar@gmail.com>
## Summary
This PR aims at relocating some of the Kibana modules (plugins and
packages) into a new folder structure, according to the _Sustainable
Kibana Architecture_ initiative.
> [!IMPORTANT]
> * We kindly ask you to:
> * Manually fix the errors in the error section below (if there are
any).
> * Search for the `packages[\/\\]` and `plugins[\/\\]` patterns in the
source code (Babel and Eslint config files), and update them
appropriately.
> * Manually review
`.buildkite/scripts/pipelines/pull_request/pipeline.ts` to ensure that
any CI pipeline customizations continue to be correctly applied after
the changed path names
> * Review all of the updated files, specially the `.ts` and `.js` files
listed in the sections below, as some of them contain relative paths
that have been updated.
> * Think of potential impact of the move, including tooling and
configuration files that can be pointing to the relocated modules. E.g.:
> * customised eslint rules
> * docs pointing to source code
> [!NOTE]
> * This PR has been auto-generated.
> * Any manual contributions will be lost if the 'relocate' script is
re-run.
> * Try to obtain the missing reviews / approvals before applying manual
fixes, and/or keep your changes in a .patch / git stash.
> * Please use
[#sustainable_kibana_architecture](https://elastic.slack.com/archives/C07TCKTA22E)
Slack channel for feedback.
Are you trying to rebase this PR to solve merge conflicts? Please follow
the steps describe
[here](https://elastic.slack.com/archives/C07TCKTA22E/p1734019532879269?thread_ts=1734019339.935419&cid=C07TCKTA22E).
#### 9 packages(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/cbor` | `src/platform/packages/shared/kbn-cbor` |
| `@kbn/repo-info` | `src/platform/packages/shared/kbn-repo-info` |
| `@kbn/repo-packages` |
`src/platform/packages/private/kbn-repo-packages` |
| `@kbn/rison` | `src/platform/packages/shared/kbn-rison` |
| `@kbn/ui-shared-deps-npm` |
`src/platform/packages/private/kbn-ui-shared-deps-npm` |
| `@kbn/ui-shared-deps-src` |
`src/platform/packages/private/kbn-ui-shared-deps-src` |
| `@kbn/ui-theme` | `src/platform/packages/shared/kbn-ui-theme` |
| `@kbn/utility-types-jest` |
`src/platform/packages/shared/kbn-utility-types-jest` |
| `@kbn/utils` | `src/platform/packages/shared/kbn-utils` |
<details >
<summary>Updated references</summary>
```
./kbn_pm/src/lib/bazel.mjs
./kbn_pm/src/lib/external_packages.js
./package.json
./packages/core/rendering/core-rendering-server-internal/src/bootstrap/get_theme_tag.ts
./packages/kbn-babel-register/BUILD.bazel
./packages/kbn-eslint-plugin-imports/src/helpers/groups.ts
./packages/kbn-monaco/BUILD.bazel
./packages/kbn-plugin-helpers/src/tasks/bazel_packages.ts
./packages/kbn-repo-packages/package-map.json
./packages/kbn-ts-projects/config-paths.json
./packages/kbn-ui-shared-deps-npm/BUILD.bazel
./packages/kbn-ui-shared-deps-src/BUILD.bazel
./src/dev/build/tasks/build_packages_task.ts
./src/platform/packages/private/kbn-repo-packages/jest.config.js
./src/platform/packages/private/kbn-repo-packages/package-map.json
./src/platform/packages/private/kbn-ui-shared-deps-src/BUILD.bazel
./src/platform/packages/shared/kbn-cbor/jest.config.js
./src/platform/packages/shared/kbn-repo-info/jest.config.js
./src/platform/packages/shared/kbn-rison/jest.config.js
./src/platform/packages/shared/kbn-utils/jest.config.js
./tsconfig.base.json
./yarn.lock
.github/CODEOWNERS
```
</details><details >
<summary>Updated relative paths</summary>
```
src/platform/packages/private/kbn-repo-packages/jest.config.js:12
src/platform/packages/private/kbn-repo-packages/tsconfig.json:2
src/platform/packages/private/kbn-ui-shared-deps-npm/tsconfig.json:2
src/platform/packages/private/kbn-ui-shared-deps-src/tsconfig.json:2
src/platform/packages/shared/kbn-cbor/jest.config.js:12
src/platform/packages/shared/kbn-cbor/tsconfig.json:12
src/platform/packages/shared/kbn-cbor/tsconfig.json:2
src/platform/packages/shared/kbn-repo-info/jest.config.js:12
src/platform/packages/shared/kbn-repo-info/tsconfig.json:2
src/platform/packages/shared/kbn-rison/jest.config.js:12
src/platform/packages/shared/kbn-rison/tsconfig.json:2
src/platform/packages/shared/kbn-ui-theme/tsconfig.json:2
src/platform/packages/shared/kbn-utility-types-jest/tsconfig.json:2
src/platform/packages/shared/kbn-utils/jest.config.js:12
src/platform/packages/shared/kbn-utils/tsconfig.json:2
```
</details>
---------
Co-authored-by: Alex Szabo <alex.szabo@elastic.co>
Co-authored-by: Jonathan Budzenski <jon@elastic.co>
Co-authored-by: Michael Dokolin <mikhail.dokolin@elastic.co>
## Summary
This PR aims at relocating some of the Kibana modules (plugins and
packages) into a new folder structure, according to the _Sustainable
Kibana Architecture_ initiative.
> [!IMPORTANT]
> * We kindly ask you to:
> * Manually fix the errors in the error section below (if there are
any).
> * Search for the `packages[\/\\]` and `plugins[\/\\]` patterns in the
source code (Babel and Eslint config files), and update them
appropriately.
> * Manually review
`.buildkite/scripts/pipelines/pull_request/pipeline.ts` to ensure that
any CI pipeline customizations continue to be correctly applied after
the changed path names
> * Review all of the updated files, specially the `.ts` and `.js` files
listed in the sections below, as some of them contain relative paths
that have been updated.
> * Think of potential impact of the move, including tooling and
configuration files that can be pointing to the relocated modules. E.g.:
> * customised eslint rules
> * docs pointing to source code
> [!NOTE]
> * This PR has been auto-generated.
> * Any manual contributions will be lost if the 'relocate' script is
re-run.
> * Try to obtain the missing reviews / approvals before applying manual
fixes, and/or keep your changes in a .patch / git stash.
> * Please use
[#sustainable_kibana_architecture](https://elastic.slack.com/archives/C07TCKTA22E)
Slack channel for feedback.
Are you trying to rebase this PR to solve merge conflicts? Please follow
the steps describe
[here](https://elastic.slack.com/archives/C07TCKTA22E/p1734019532879269?thread_ts=1734019339.935419&cid=C07TCKTA22E).
#### 6 plugin(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/apm-data-access-plugin` |
`x-pack/solutions/observability/plugins/apm_data_access` |
| `@kbn/apm-plugin` | `x-pack/solutions/observability/plugins/apm` |
| `@kbn/inventory-plugin` |
`x-pack/solutions/observability/plugins/inventory` |
| `@kbn/metrics-data-access-plugin` |
`x-pack/solutions/observability/plugins/metrics_data_access` |
| `@kbn/profiling-data-access-plugin` |
`x-pack/solutions/observability/plugins/profiling_data_access` |
| `@kbn/profiling-plugin` |
`x-pack/solutions/observability/plugins/profiling` |
#### 6 packages(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/apm-data-view` |
`src/platform/packages/shared/kbn-apm-data-view` |
| `@kbn/apm-types` |
`x-pack/solutions/observability/packages/kbn-apm-types` |
| `@kbn/apm-utils` | `src/platform/packages/shared/kbn-apm-utils` |
| `@kbn/lens-embeddable-utils` |
`src/platform/packages/shared/kbn-lens-embeddable-utils` |
| `@kbn/profiling-utils` |
`src/platform/packages/shared/kbn-profiling-utils` |
| `@kbn/shared-svg` | `src/platform/packages/shared/kbn-shared-svg` |
<details >
<summary>Updated references</summary>
```
./.buildkite/ftr_oblt_stateful_configs.yml
./.buildkite/scripts/steps/functional/apm_cypress.sh
./.buildkite/scripts/steps/functional/inventory_cypress.sh
./.buildkite/scripts/steps/functional/profiling_cypress.sh
./.eslintrc.js
./.github/paths-labeller.yml
./.gitignore
./docs/developer/plugin-list.asciidoc
./oas_docs/overlays/alerting.overlays.yaml
./oas_docs/scripts/merge_ess_oas.js
./oas_docs/scripts/merge_serverless_oas.js
./package.json
./packages/kbn-eslint-plugin-i18n/helpers/get_i18n_identifier_from_file_path.test.ts
./packages/kbn-eslint-plugin-telemetry/helpers/get_app_name.test.ts
./packages/kbn-repo-packages/package-map.json
./packages/kbn-ts-projects/config-paths.json
./src/dev/precommit_hook/casing_check_config.js
./src/dev/storybook/aliases.ts
./src/platform/packages/shared/kbn-lens-embeddable-utils/jest.config.js
./src/platform/packages/shared/kbn-profiling-utils/jest.config.js
./src/platform/packages/shared/kbn-shared-svg/jest.config.js
./tsconfig.base.json
./x-pack/.i18nrc.json
./x-pack/platform/packages/shared/ml/aiops_log_rate_analysis/queries/fetch_index_info.ts
./x-pack/platform/packages/shared/ml/aiops_log_rate_analysis/queries/fetch_significant_term_p_values.ts
./x-pack/platform/packages/shared/ml/aiops_log_rate_analysis/queries/fetch_top_terms.ts
./x-pack/platform/plugins/private/data_visualizer/public/application/index_data_visualizer/utils/saved_search_utils.ts
./x-pack/solutions/observability/plugins/apm/common/rules/apm_rule_types.ts
./x-pack/solutions/observability/plugins/apm/dev_docs/apm_queries.md
./x-pack/solutions/observability/plugins/apm/dev_docs/linting.md
./x-pack/solutions/observability/plugins/apm/dev_docs/local_setup.md
./x-pack/solutions/observability/plugins/apm/dev_docs/telemetry.md
./x-pack/solutions/observability/plugins/apm/dev_docs/testing.md
./x-pack/solutions/observability/plugins/apm/dev_docs/updating_functional_tests_archives.md
./x-pack/solutions/observability/plugins/apm/dev_docs/vscode_setup.md
./x-pack/solutions/observability/plugins/apm/ftr_e2e/README.md
./x-pack/solutions/observability/plugins/apm/jest.config.js
./x-pack/solutions/observability/plugins/apm/scripts/infer_route_return_types/index.ts
./x-pack/solutions/observability/plugins/apm/scripts/precommit.js
./x-pack/solutions/observability/plugins/apm/scripts/telemetry/main.ts
./x-pack/solutions/observability/plugins/apm_data_access/jest.config.js
./x-pack/solutions/observability/plugins/exploratory_view/common/annotations.ts
./x-pack/solutions/observability/plugins/inventory/README.md
./x-pack/solutions/observability/plugins/inventory/jest.config.js
./x-pack/solutions/observability/plugins/metrics_data_access/jest.config.js
./x-pack/solutions/observability/plugins/observability/common/annotations.ts
./x-pack/solutions/observability/plugins/profiling/README.md
./x-pack/solutions/observability/plugins/profiling/e2e/README.md
./x-pack/solutions/observability/plugins/profiling/jest.config.js
./x-pack/solutions/observability/plugins/profiling_data_access/jest.config.js
./x-pack/solutions/security/plugins/security_solution/server/utils/build_query/calculate_timeseries_interval.ts
./yarn.lock
.github/CODEOWNERS
```
</details><details >
<summary>Updated relative paths</summary>
```
src/platform/packages/shared/kbn-apm-data-view/tsconfig.json:2
src/platform/packages/shared/kbn-apm-utils/tsconfig.json:2
src/platform/packages/shared/kbn-lens-embeddable-utils/jest.config.js:12
src/platform/packages/shared/kbn-lens-embeddable-utils/tsconfig.json:2
src/platform/packages/shared/kbn-profiling-utils/jest.config.js:12
src/platform/packages/shared/kbn-profiling-utils/tsconfig.json:2
src/platform/packages/shared/kbn-shared-svg/jest.config.js:12
src/platform/packages/shared/kbn-shared-svg/tsconfig.json:2
x-pack/solutions/observability/packages/kbn-apm-types/tsconfig.json:2
x-pack/solutions/observability/plugins/apm/dev_docs/telemetry.md:17
x-pack/solutions/observability/plugins/apm/dev_docs/telemetry.md:22
x-pack/solutions/observability/plugins/apm/dev_docs/testing.md:130
x-pack/solutions/observability/plugins/apm/dev_docs/testing.md:222
x-pack/solutions/observability/plugins/apm/dev_docs/testing.md:78
x-pack/solutions/observability/plugins/apm/dev_docs/testing.md:96
x-pack/solutions/observability/plugins/apm/dev_docs/vscode_setup.md:42
x-pack/solutions/observability/plugins/apm/ftr_e2e/README.md:3
x-pack/solutions/observability/plugins/apm/ftr_e2e/tsconfig.json:2
x-pack/solutions/observability/plugins/apm/jest.config.js:12
x-pack/solutions/observability/plugins/apm/scripts/infer_route_return_types/index.ts:125
x-pack/solutions/observability/plugins/apm/scripts/precommit.js:15
x-pack/solutions/observability/plugins/apm/scripts/precommit.js:33
x-pack/solutions/observability/plugins/apm/scripts/precommit.js:38
x-pack/solutions/observability/plugins/apm/scripts/precommit.js:50
x-pack/solutions/observability/plugins/apm/scripts/shared/read_kibana_config.ts:16
x-pack/solutions/observability/plugins/apm/tsconfig.json:2
x-pack/solutions/observability/plugins/apm/tsconfig.json:7
x-pack/solutions/observability/plugins/apm_data_access/jest.config.js:12
x-pack/solutions/observability/plugins/apm_data_access/tsconfig.json:2
x-pack/solutions/observability/plugins/apm_data_access/tsconfig.json:6
x-pack/solutions/observability/plugins/inventory/e2e/tsconfig.json:2
x-pack/solutions/observability/plugins/inventory/jest.config.js:10
x-pack/solutions/observability/plugins/inventory/tsconfig.json:2
x-pack/solutions/observability/plugins/inventory/tsconfig.json:7
x-pack/solutions/observability/plugins/metrics_data_access/jest.config.js:10
x-pack/solutions/observability/plugins/metrics_data_access/tsconfig.json:2
x-pack/solutions/observability/plugins/metrics_data_access/tsconfig.json:6
x-pack/solutions/observability/plugins/profiling/README.md:52
x-pack/solutions/observability/plugins/profiling/e2e/README.md:3
x-pack/solutions/observability/plugins/profiling/e2e/tsconfig.json:11
x-pack/solutions/observability/plugins/profiling/e2e/tsconfig.json:2
x-pack/solutions/observability/plugins/profiling/jest.config.js:10
x-pack/solutions/observability/plugins/profiling/tsconfig.json:2
x-pack/solutions/observability/plugins/profiling_data_access/jest.config.js:12
x-pack/solutions/observability/plugins/profiling_data_access/tsconfig.json:2
```
</details>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR aims at relocating some of the Kibana modules (plugins and
packages) into a new folder structure, according to the _Sustainable
Kibana Architecture_ initiative.
> [!IMPORTANT]
> * We kindly ask you to:
> * Manually fix the errors in the error section below (if there are
any).
> * Search for the `packages[\/\\]` and `plugins[\/\\]` patterns in the
source code (Babel and Eslint config files), and update them
appropriately.
> * Manually review
`.buildkite/scripts/pipelines/pull_request/pipeline.ts` to ensure that
any CI pipeline customizations continue to be correctly applied after
the changed path names
> * Review all of the updated files, specially the `.ts` and `.js` files
listed in the sections below, as some of them contain relative paths
that have been updated.
> * Think of potential impact of the move, including tooling and
configuration files that can be pointing to the relocated modules. E.g.:
> * customised eslint rules
> * docs pointing to source code
> [!NOTE]
> * This PR has been auto-generated.
> * Any manual contributions will be lost if the 'relocate' script is
re-run.
> * Try to obtain the missing reviews / approvals before applying manual
fixes, and/or keep your changes in a .patch / git stash.
> * Please use
[#sustainable_kibana_architecture](https://elastic.slack.com/archives/C07TCKTA22E)
Slack channel for feedback.
Are you trying to rebase this PR to solve merge conflicts? Please follow
the steps describe
[here](https://elastic.slack.com/archives/C07TCKTA22E/p1734019532879269?thread_ts=1734019339.935419&cid=C07TCKTA22E).
#### 2 plugin(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/custom-integrations-plugin` |
`src/platform/plugins/shared/custom_integrations` |
| `@kbn/fleet-plugin` | `x-pack/platform/plugins/shared/fleet` |
#### 1 packages(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/deeplinks-fleet` |
`src/platform/packages/shared/deeplinks/fleet` |
<details open>
<summary>Script errors</summary>
```
Cannot replace multiple occurrences of "../.." in the same line, please fix manually: /Users/pgayvallet/DEV/workspaces/elastic/kibana/x-pack/platform/plugins/shared/fleet/cypress/README.md:122
Cannot replace multiple occurrences of "../.." in the same line, please fix manually: /Users/pgayvallet/DEV/workspaces/elastic/kibana/x-pack/platform/plugins/shared/fleet/cypress/README.md:128
Cannot replace multiple occurrences of "../.." in the same line, please fix manually: /Users/pgayvallet/DEV/workspaces/elastic/kibana/x-pack/platform/plugins/shared/fleet/package.json:12
Cannot replace multiple occurrences of "../.." in the same line, please fix manually: /Users/pgayvallet/DEV/workspaces/elastic/kibana/x-pack/platform/plugins/shared/fleet/package.json:12
Cannot replace multiple occurrences of "../.." in the same line, please fix manually: /Users/pgayvallet/DEV/workspaces/elastic/kibana/x-pack/platform/plugins/shared/fleet/package.json:8
Cannot replace multiple occurrences of "../.." in the same line, please fix manually: /Users/pgayvallet/DEV/workspaces/elastic/kibana/x-pack/platform/plugins/shared/fleet/package.json:8
Cannot replace multiple occurrences of "../../.." in the same line, please fix manually: /Users/pgayvallet/DEV/workspaces/elastic/kibana/x-pack/platform/plugins/shared/fleet/cypress/README.md:122
Cannot replace multiple occurrences of "../../.." in the same line, please fix manually: /Users/pgayvallet/DEV/workspaces/elastic/kibana/x-pack/platform/plugins/shared/fleet/cypress/README.md:128
Cannot replace multiple occurrences of "../../.." in the same line, please fix manually: /Users/pgayvallet/DEV/workspaces/elastic/kibana/x-pack/platform/plugins/shared/fleet/package.json:16
Cannot replace multiple occurrences of "../../.." in the same line, please fix manually: /Users/pgayvallet/DEV/workspaces/elastic/kibana/x-pack/platform/plugins/shared/fleet/package.json:16
Cannot replace multiple occurrences of "../../.." in the same line, please fix manually: /Users/pgayvallet/DEV/workspaces/elastic/kibana/x-pack/platform/plugins/shared/fleet/package.json:16
Cannot replace multiple occurrences of "../../.." in the same line, please fix manually: /Users/pgayvallet/DEV/workspaces/elastic/kibana/x-pack/platform/plugins/shared/fleet/package.json:16
Cannot replace multiple occurrences of "../../.." in the same line, please fix manually: /Users/pgayvallet/DEV/workspaces/elastic/kibana/x-pack/platform/plugins/shared/fleet/package.json:16
Cannot replace multiple occurrences of "../../.." in the same line, please fix manually: /Users/pgayvallet/DEV/workspaces/elastic/kibana/x-pack/platform/plugins/shared/fleet/package.json:16
Cannot replace multiple occurrences of "../../.." in the same line, please fix manually: /Users/pgayvallet/DEV/workspaces/elastic/kibana/x-pack/platform/plugins/shared/fleet/package.json:16
Cannot replace multiple occurrences of "../../.." in the same line, please fix manually: /Users/pgayvallet/DEV/workspaces/elastic/kibana/x-pack/platform/plugins/shared/fleet/package.json:16
```
</details><details >
<summary>Updated relative paths</summary>
```
src/platform/packages/shared/deeplinks/fleet/jest.config.js:12
src/platform/packages/shared/deeplinks/fleet/tsconfig.json:2
src/platform/packages/shared/deeplinks/fleet/tsconfig.type_check.json:2
src/platform/plugins/shared/custom_integrations/jest.config.js:12
src/platform/plugins/shared/custom_integrations/tsconfig.json:2
src/platform/plugins/shared/custom_integrations/tsconfig.json:7
src/platform/plugins/shared/custom_integrations/tsconfig.type_check.json:2
src/platform/plugins/shared/custom_integrations/tsconfig.type_check.json:20
src/platform/plugins/shared/custom_integrations/tsconfig.type_check.json:26
src/platform/plugins/shared/custom_integrations/tsconfig.type_check.json:29
src/platform/plugins/shared/custom_integrations/tsconfig.type_check.json:32
src/platform/plugins/shared/custom_integrations/tsconfig.type_check.json:35
src/platform/plugins/shared/custom_integrations/tsconfig.type_check.json:38
src/platform/plugins/shared/custom_integrations/tsconfig.type_check.json:41
src/platform/plugins/shared/custom_integrations/tsconfig.type_check.json:9
x-pack/platform/plugins/shared/fleet/cypress.config.js:22
x-pack/platform/plugins/shared/fleet/cypress.config.js:25
x-pack/platform/plugins/shared/fleet/cypress.config.space_awareness.ts:26
x-pack/platform/plugins/shared/fleet/cypress.config.space_awareness.ts:29
x-pack/platform/plugins/shared/fleet/cypress.config.ts:25
x-pack/platform/plugins/shared/fleet/cypress.config.ts:28
x-pack/platform/plugins/shared/fleet/cypress/README.md:122
x-pack/platform/plugins/shared/fleet/cypress/README.md:128
x-pack/platform/plugins/shared/fleet/cypress/reporter_config.json:6
x-pack/platform/plugins/shared/fleet/cypress/reporter_config.json:8
x-pack/platform/plugins/shared/fleet/cypress/tasks/login.ts:21
x-pack/platform/plugins/shared/fleet/cypress/tsconfig.json:2
x-pack/platform/plugins/shared/fleet/cypress/tsconfig.json:7
x-pack/platform/plugins/shared/fleet/cypress/tsconfig.type_check.json:2
x-pack/platform/plugins/shared/fleet/cypress/tsconfig.type_check.json:25
x-pack/platform/plugins/shared/fleet/cypress/tsconfig.type_check.json:28
x-pack/platform/plugins/shared/fleet/cypress/tsconfig.type_check.json:31
x-pack/platform/plugins/shared/fleet/cypress/tsconfig.type_check.json:37
x-pack/platform/plugins/shared/fleet/cypress/tsconfig.type_check.json:40
x-pack/platform/plugins/shared/fleet/cypress/tsconfig.type_check.json:7
x-pack/platform/plugins/shared/fleet/jest.config.js:10
x-pack/platform/plugins/shared/fleet/jest.integration.config.js:10
x-pack/platform/plugins/shared/fleet/package.json:11
x-pack/platform/plugins/shared/fleet/package.json:12
x-pack/platform/plugins/shared/fleet/package.json:15
x-pack/platform/plugins/shared/fleet/package.json:16
x-pack/platform/plugins/shared/fleet/package.json:8
x-pack/platform/plugins/shared/fleet/scripts/create_agent_policies/index.js:8
x-pack/platform/plugins/shared/fleet/scripts/create_agents/index.js:8
x-pack/platform/plugins/shared/fleet/scripts/get_all_packages/index.js:8
x-pack/platform/plugins/shared/fleet/scripts/install_all_packages/index.js:8
x-pack/platform/plugins/shared/fleet/scripts/verify_test_packages/index.js:8
x-pack/platform/plugins/shared/fleet/scripts/verify_test_packages/verify_test_packages.ts:25
x-pack/platform/plugins/shared/fleet/scripts/verify_test_packages/verify_test_packages.ts:26
x-pack/platform/plugins/shared/fleet/scripts/verify_test_packages/verify_test_packages.ts:27
x-pack/platform/plugins/shared/fleet/tsconfig.json:2
x-pack/platform/plugins/shared/fleet/tsconfig.json:22
x-pack/platform/plugins/shared/fleet/tsconfig.json:26
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:102
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:105
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:111
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:114
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:120
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:123
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:126
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:129
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:132
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:135
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:144
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:147
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:150
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:153
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:156
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:159
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:162
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:165
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:168
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:171
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:174
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:177
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:180
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:183
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:186
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:189
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:192
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:195
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:198
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:2
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:201
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:204
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:207
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:210
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:213
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:216
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:219
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:222
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:225
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:228
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:23
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:231
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:234
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:237
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:240
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:243
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:246
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:249
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:252
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:255
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:261
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:264
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:27
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:270
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:273
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:276
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:279
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:30
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:36
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:42
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:45
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:57
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:60
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:63
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:66
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:72
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:75
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:78
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:81
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:84
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:87
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:90
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:93
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:96
x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json:99
```
</details>
---------
Co-authored-by: pgayvallet <pierre.gayvallet@elastic.co>
Co-authored-by: Nicolas Chaulet <nicolas.chaulet@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR introduces a new package, **kbn-scout**, designed to streamline
the setup and execution of Playwright tests for Kibana. The `kbn-scout`
package consolidates server management and testing capabilities by
wrapping both the Kibana/Elasticsearch server launcher and the
Playwright test runner. It includes:
- Test and worker-scoped fixtures for reliable setup across test suites
- Page objects combined into the fixture for Kibana UI interactions
- Configurations for seamless test execution in both local and CI
environments (`Cloud` execution is out of scope)
- This package aims to simplify test setup and enhance modularity,
making it easier to create, run, and maintain deployment-agnostic tests,
that are located in the plugin they actually test.
Tests example is available in `x-pack/plugins/discover_enhanced` plugin
under `ui_tests` folder
How to run:
1) As a single script (servers + tests):
```
node scripts/scout_test.js --config=x-pack/plugins/discover_enhanced/ui_tests/playwright.config.ts --serverless=es
```
2) Start servers first
```
node scripts/scout_start_servers.js --serverless=es
```
then run tests:
```
npx playwright test --config=x-pack/plugins/discover_enhanced/ui_tests/playwright.config.ts
```
if you have Playwright plugin in IDEA, just use it to run tests files
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
[dependency-cruiser](https://github.com/sverweij/dependency-cruiser/tree/main)
is used for building dependency graph.
### Show all dependencies for a specific package/plugin or directory
#### Run for all plugins
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins -o ./tmp/deps-result-all.json
```
#### Run for single plugin
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution -o ./tmp/deps-result-single.json
```
#### Run for multiple plugins
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution x-pack/plugins/security -o ./tmp/deps-result-multiple.json
```
#### Run for `x-pack/packages`
```bash
bash scripts/dependency_usage.sh -p x-pack/packages -o ./tmp/deps-packages-1.json
```
#### Run for `packages`
```bash
bash scripts/dependency_usage.sh -p packages -o ./tmp/deps-packages-2.json
```
#### Benchmark
| Analysis | Real Time | User Time | Sys Time |
|-----------------------|-------------|-------------|------------|
| All plugins | 7m 21.126s | 7m 53.099s | 20.581s |
| Single plugin | 31.360s | 45.352s | 2.208s |
| Multiple plugins | 36.403s | 50.563s | 2.814s |
| x-pack/packages | 6.638s | 12.646s | 0.654s |
| packages | 25.744s | 39.073s | 2.191s |
#### Show all packages/plugins within a directory that use a specific
dependency
```sh
bash scripts/dependency_usage.sh -d rxjs -p x-pack/plugins/security_solution
```
---
#### Show all packages/plugins within a directory grouped by code owner
```sh
bash scripts/dependency_usage.sh -d rxjs -p x-pack/plugins -g owner
```
---
#### Group by code owner with adjustable collapse depth for fine-grained
grouping
**Fine-grained grouping**:
```sh
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution -g owner --collapse-depth 4
```
**Collapsed grouping**: groups the results under a higher-level owner
(e.g., `security_solution` as a single group).
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution -g owner --collapse-depth 1
```
---
#### Show all dependencies matching a pattern (e.g., `react-*`) within a
package
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution -d 'react-*' -o ./tmp/result.json
```
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [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
__Related: https://github.com/elastic/kibana/issues/196767__
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR introduces a script that allows developers to run CodeQL
analysis locally. It uses a Docker container with prebuilt CodeQL
queries to facilitate easy setup and execution.
The script has the following key steps:
- Creating a CodeQL database from the source code. The database is
essentially a representation of the codebase that CodeQL uses to analyze
for potential issues.
- Running the analysis on the created database,
`javascript-security-and-quality` suit is used.
### Usage
```
bash scripts/codeql/quick_check.sh -s path/to/your-source-dir
```
For example
```
bash scripts/codeql/quick_check.sh -s ./x-pack/plugins/security_solution/public/common/components/ml/conditional_links
```
The `-s` option allows you to specify the path to the source code
directory that you wish to analyze.
### Why custom Docker file?
Checked the ability to use MSFT image for local run
https://github.com/microsoft/codeql-container. Turned out it has several
problems:
1. The published one has an error with [execute
permissions](https://github.com/microsoft/codeql-container/issues/53).
2. Container has outdated nodejs version, so it didn't parse our syntax
(like `??`) and failed.
3. The technique used in the repository to download the CodeQL binaries
and precompile the queries is outdated in the sense that GitHub now
offers pre-compiled queries you can just download. Follow this
[comment](https://github.com/microsoft/codeql-container/issues/53#issuecomment-1875879512).
Taking this into consideration I have created a lightweight docker image
without extraneous dependencies for go/.net/java.
## Context and interdependencies issues
There are issues sometimes when analyze run returns no results,
particularly when analyzing a single folder.
It might be due to the missing context for the data flow graph CodeQL
generates or context for interdependencies. This is actually a trade off
of running it locally for a subset of source directories. We need to
explicitly state that in the documentation and advise to expand the
scope of source code directories involved for local scan.
Documentation for triaging issues will be updated separately.
__Closes: https://github.com/elastic/kibana/issues/195740__
## UPDATE
It has been removed the execution of the playwright tests on buildkite,
the execution will be re-enabled as soon as we are ready and as
described below in the PR, there are still steps pending to be done.
## Motivation
**Cypress is not performing well lately.**
* We have been facing significant performance issues with Cypress. For
instance, it takes a long time to open the visual interface and start
executing tests.
**Teams are finding it increasingly challenging to write new tests and
debug existing ones.**
* The time and effort required to create new tests or troubleshoot
existing ones have become burdensome.
**Concern about the impact this could have on our testing practices.**
* Lose motivation to write tests or, worse, skip writing crucial tests.
## Why Playwright?
* Compared to Cypress, Playwright seems to be known for its faster
execution times and lower resource consumption. What could have a
positive impact by having faster feedback during development and
execution of new tests as well as more efficient use of CI resources.
* Provides powerful debugging tools which can make easier to write,
debug and execute tests.
* Seems to provide the same capabilities we currently use in our Cypress
tests.
* Given Playwright's active development and backing by Microsoft, it is
likely to continue evolving rapidly, making it a safe long-term choice.
Considering all the above, Playwright seems to be a strong candidate to
replace Cypress and address all the issues we are facing lately
regarding UI test automation.
## Objective of this POC
To write in Playwright a couple of tests we currently have on Cypress to
check the performance of the tool as well as the development experience.
The tests selected have been:
-
[enable_risk_score_redirect.cy.ts](https://github.com/elastic/kibana/blob/main/x-pack/test/security_solution_cypress/cypress/e2e/entity_analytics/dashboards/enable_risk_score_redirect.cy.ts)
- Owned by Entity Analytics team and selected by its simplicity since it
does not need any special setup to be executed and is short.
-
[manual_rule_run.cy.ts](https://github.com/elastic/kibana/blob/main/x-pack/test/security_solution_cypress/cypress/e2e/detection_response/detection_engine/rule_gaps/manual_rule_run.cy.ts)
- Owned by Detection Engine team and selected because is short and adds
a bit more of complexity due to it needs of clean-up and setting up
initial data through the API.
## How to execute the tests
### Visual mode
- Navigate to: `x-pack/test/security_solution_playwright`
- Execute: `yarn open:ess` for ESS environment or `yarn open:serverless`
for serverless environment.
### Headless mode
- Navigate to: `x-pack/test/security_solution_playwright`
- Execute: `yarn run:ess` for ESS environment or `yarn run:serverless`
for serverless environment.
### From VScode
- Install `Playwright Test for VScode` extension by Microsoft
- Navigate to: `x-pack/test/security_solution_playwright`
- Execute: `yarn open:ess` for ESS environment or `yarn open:serverless`
for serverless environment.
- Open your IDE
- Click on the `Testing` icon
- On the `Test Explorer` click on the three dots to select the profile
you are going to execute `ess` or `serverless`
- Click on the test you want to execute or navigate to the spec file of
the test and execute it from the same spec.
## My experience
- Tests are way easier to implement than with Cypress.
- Playwright does not rely on chainable commands. Chainable commands on
Cypress can lead to confusing code.
- Without chainable commands, the flow of the tests is more explicit and
easier to understand.
- You can notice that the tool has been designed with Typescript in
mind.
- Is super easy to implement the Page Object Model pattern (POM).
- With POM the test code is clean and focused on "what" rather than
"how".
- Love the fact that you can execute the tests from the same IDE without
having to switch windows during test development.
- The visual mode execution gives you lots of information out of the
box.
## The scope of this PR
- Sets the initial infrastructure to write and execute tests with
Playwright.
- Has examples and set a basis about how to write tests using the POM.
- Allows the execution of the tests in ESS and serverless (just
stateless environment).
- Integrates the execution of the tests with buildkite.
## Pending to be done/investigate
- Proper readme
- How to split tests and PO between the different teams
- Good reports on CI
- Upload screenshots on CI
- Flaky test suite runner
- Complete the labeling
- Execution of the tests on MKI environments
## FAQ
**Can I start adding tests to playwright?**
Currently, you can explore and experiment with Playwright, but there is
still work pending to be done to make the tool officially usable.
**Why security engineering productivity is the owner of the playwright
folder?**
This is something temporary to make sure that good practices are
followed.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: dkirchan <diamantis.kirchantzoglou@elastic.co>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Co-authored-by: Jon <jon@budzenski.me>
## Summary
- Closeselastic/kibana-operations#101
This PR adds a [Dev Container](https://containers.dev/) to utilize for
Kibana local development in an isolated environment. The original
intention was to create a local environment for FIPS development because
setting up Kibana in FIPS mode is complicated and has the potential to
break the user's OS. However, it has been altered to allow for general
development if an engineer chooses as well. The idea is for this be a
cost efficient replacement for
[kibana-remote-dev](https://github.com/elastic/kibana-remote-dev)
eventually.
### Testing
- In VS Code you should be able to use the `Dev Containers: Clone GitHub
Pull Request in Named Container Volume...` command from the Command
Palette (F1) to easily test this PR.
- See the
[docs](bd125fc230/dev_docs/getting_started/setting_up_a_development_env.mdx (using-the-kibana-dev-container-optional))
for additional information on setting up the Dev Container.
### Bazel
I tried many different solutions to copy the local Bazel cache into the
container to speed up bootstrap, but it either would break Bazel or
didn't provide any meaningful boost in performance. I opted to forgo
keeping it in this PR due to the complexity and since we're planning to
phase out Bazel in the future anyways.
## Summary
### This PR enables user roles testing in FTR
We use SAML authentication to get session cookie for user with the
specific role. The cookie is cached on FTR service side so we only make
SAML auth one time per user within FTR config run. For Kibana CI service
relies on changes coming in #170852
In order to run FTR tests locally against existing MKI project:
- add `.ftr/role_users.json` in Kibana root dir
```
{
"viewer": {
"email": "...",
"password": "..."
},
"developer": {
"email": "...",
"password": "..."
}
}
```
- set Cloud hostname (!not project hostname!) with TEST_CLOUD_HOST_NAME,
e.g.
`export TEST_CLOUD_HOST_NAME=console.qa.cld.elstc.co`
### How to use:
- functional tests:
```
const svlCommonPage = getPageObject('svlCommonPage');
before(async () => {
// login with Viewer role
await svlCommonPage.loginWithRole('viewer');
// you are logged in in browser and on project home page, start the test
});
it('has project header', async () => {
await svlCommonPage.assertProjectHeaderExists();
});
```
- API integration tests:
```
const svlUserManager = getService('svlUserManager');
const supertestWithoutAuth = getService('supertestWithoutAuth');
let credentials: { Cookie: string };
before(async () => {
// get auth header for Viewer role
credentials = await svlUserManager.getApiCredentialsForRole('viewer');
});
it('returns full status payload for authenticated request', async () => {
const { body } = await supertestWithoutAuth
.get('/api/status')
.set(credentials)
.set('kbn-xsrf', 'kibana');
expect(body.name).to.be.a('string');
expect(body.uuid).to.be.a('string');
expect(body.version.number).to.be.a('string');
});
```
Flaky-test-runner:
#1https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/4081#2https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/4114
---------
Co-authored-by: Robert Oskamp <traeluki@gmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Added snapshots to the service map e2e test and other improvements.
Due to flakiness of the visual regression tests, we leave them skipped,
and we can continue investigating, this issue
https://github.com/elastic/kibana/issues/166050 was created with this
porpoise.
---------
Co-authored-by: Søren Louv-Jansen <soren.louv@elastic.co>
Ensure that a plugin containing a nested `node_modules` folder correctly
identifies imports from that folder as regular node modules instead of relative imports.
Kibana should currently only have a single root `node_modules` folder, so this should
not be a real issue. However, if for some reason a stray `node_modules` folder is
created, this commit will make sure it's not introducing hard to debug ESLint errors.
Includes a few compiled cypress typescript files generated during `node
scripts/type_check`. We're not using a global glob due to some plugins
using a javascript base.
This adds an overview of the number of documents per document type. It's
possible to filter the data via search bar and time range.
<img width="1478" alt="image"
src="32c1c79c-c76a-4b84-ab16-c1b1faccba32">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Pitch: https://github.com/elastic/apm-dev/issues/872 (_internal_)
Introduces the Diagnostics tool under a hidden page:
`/app/apm/diagnostics`. The Diagnostics tool can help find problems with
missing index templates, data streams with incorrect index templates and
indices with incorrect mappings.
It will be released in 8.9 but customers can take advantage of it as
soon as this PR is merged. They can export a diagnostics bundle from
their system by running this script:
```
node x-pack/plugins/apm/scripts/diagnostics_bundle \
--kbHost https://foo.kb.europe-west2.gcp.elastic-cloud.com:9243 \
--esHost https://foo.es.europe-west2.gcp.elastic-cloud.com:9243 \
--username elastic
--password changeme
```
---------
Co-authored-by: Yngrid Coello <yngrdyn@gmail.com>
## Summary
This PR adds boilerplate code and a few initial end-to-end tests to
serverless plugins.
Note that the tests defined in this PR are not part of any CI run yet,
this will be done in a follow-up after this PR is merged.
### Details
The serverless test structure corresponds to what we have in
`x-pack/test` with API tests in `api_integration` and UI tests in
`functional`, each with their set of helper methods and sub-directories
for
- `common` functionality shared across serverless projects (core, shared
UX, ...)
- `observability` project specific functionality
- `search` project specific functionality
- `security` project specific functionality
The `shared` directory contains fixtures, services, ... that are shared
across `api_integration` abd `functional` tests.
```
x-pack/test_serverless/
├─ api_integration
│ ├─ services
│ ├─ test_suites
│ │ ├─ common
│ │ ├─ observability
│ │ ├─ search
│ │ ├─ security
├─ functional
│ ├─ page_objects
│ ├─ services
│ ├─ test_suites
│ │ ├─ common
│ │ ├─ observability
│ │ ├─ search
│ │ ├─ security
├─ shared
│ ├─ services
│ ├─ types
```
See also `x-pack/test_serverless/README.md`
### Run tests
Similar to how functional tests are run in `x-pack/test`, you can point
the functional tests server and test runner to config files in this
`x-pack/test_serverless` directory, e.g. from the `x-pack` directory
run:
```
node scripts/functional_tests_server.js --config test_serverless/api_integration/test_suites/common/config.ts
```
and
```
node scripts/functional_test_runner.js --config test_serverless/api_integration/test_suites/common/config.ts
```
### Additional changes
- The stateful `common_page` page object used the existence of the
global nav to determine `isChromeVisible` and `isChromeHidden`, which is
not working when the global nav is disabled. To solve this, a
`data-test-subj` that indicates the chrome visible state is added to the
Kibana app wrapper and is used for the checks.
- Add a few `data-test-subj` entries to the Observability overview page.
- Add optional `dataTestSubj` to the `Navigation` component and use that
for the serverless search nav.
- Add optional `titleDataTestSubj` to the `SolutionNav` component and
use it for the serverless security nav.
- Add a data-test-subj entry to the Search overview page.
Fixes https://github.com/elastic/kibana/issues/149344
This PR migrates all plugins to packages automatically. It does this
using `node scripts/lint_packages` to automatically migrate
`kibana.json` files to `kibana.jsonc` files. By doing this automatically
we can simplify many build and testing procedures to only support
packages, and not both "packages" and "synthetic packages" (basically
pointers to plugins).
The majority of changes are in operations related code, so we'll be
having operations review this before marking it ready for review. The
vast majority of the code owners are simply pinged because we deleted
all `kibana.json` files and replaced them with `kibana.jsonc` files, so
we plan on leaving the PR ready-for-review for about 24 hours before
merging (after feature freeze), assuming we don't have any blockers
(especially from @elastic/kibana-core since there are a few core
specific changes, though the majority were handled in #149370).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
We are currently expecting serverless environments to be broken up into
several different envs, this config structure allows us to customize the
config based on that environment without major modifications to the
config loading system.
This adds the `--serverless` CLI arg (only available in dev mode, you
can also use `yarn start-serverless`), which will load the new
`config/kibana.serverless.yml` file. For now, this file is not included
in the build artifact, though we might include a `--serverless` flag
which replaces the `kibana.yml` file with `kibana.serverless.yml`.
@jbudz will follow up after this PR with the build related changes to
get this working with PR cloud deploys, which will be enough changes for
us to start iterating on UI specific changes based on running in a
serverless environment.
Additionally, support for the undocumented `KBN_CONFIG_PATHS` env var is
added, which should contain a comma-separated list of paths to kibana
config files. These files are loaded, in the specified order, before any
of the config files listed in the CLI but after the kibana.yml config
file.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
The location of plugins was previously somewhat irrelevant, but as we
move into packages it's more important that we can find all plugins in
the repository, and we would like to be able to do that without needing
to maintain a manifest somewhere to accomplish this. In order to make
this possible we plan to find any plugin/package by spotting all
kibana.json files which are not "fixtures". This allows plugin-like code
(but not actual plugin code) to exist for testing purposes, but it must
be within some form of "fixtures" directory, and any plugin that isn't
in a fixtures directory will be automatically pulled into the system
(though test plugins, examples, etc. will still only be loaded when the
plugin's path is passed via `--plugin-path`, the system will know about
them and use that knowledge for other things).
Since this is just a rename Operations will review and merge by EOD Jan
12th unless someone has a blocking concern.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR implements a linter like the TS Project linter, except for
packages in the repo. It does this by extracting the reusable bits from
the TS Project linter and reusing them for the project linter. The only
rule that exists for packages right now is that the "name" in the
package.json file matches the "id" in Kibana.jsonc. The goal is to use a
rule to migrate kibana.json files on the future.
Additionally, a new rule for validating the indentation of tsconfig.json
files was added.
Validating and fixing violations is what has triggered review by so many
teams, but we plan to treat those review requests as notifications of
the changes and not as blockers for merging.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Dearest Reviewers 👋
I've been working on this branch with @mistic and @tylersmalley and
we're really confident in these changes. Additionally, this changes code
in nearly every package in the repo so we don't plan to wait for reviews
to get in before merging this. If you'd like to have a concern
addressed, please feel free to leave a review, but assuming that nobody
raises a blocker in the next 24 hours we plan to merge this EOD pacific
tomorrow, 12/22.
We'll be paying close attention to any issues this causes after merging
and work on getting those fixed ASAP. 🚀
---
The operations team is not confident that we'll have the time to achieve
what we originally set out to accomplish by moving to Bazel with the
time and resources we have available. We have also bought ourselves some
headroom with improvements to babel-register, optimizer caching, and
typescript project structure.
In order to make sure we deliver packages as quickly as possible (many
teams really want them), with a usable and familiar developer
experience, this PR removes Bazel for building packages in favor of
using the same JIT transpilation we use for plugins.
Additionally, packages now use `kbn_references` (again, just copying the
dx from plugins to packages).
Because of the complex relationships between packages/plugins and in
order to prepare ourselves for automatic dependency detection tools we
plan to use in the future, this PR also introduces a "TS Project Linter"
which will validate that every tsconfig.json file meets a few
requirements:
1. the chain of base config files extended by each config includes
`tsconfig.base.json` and not `tsconfig.json`
1. the `include` config is used, and not `files`
2. the `exclude` config includes `target/**/*`
3. the `outDir` compiler option is specified as `target/types`
1. none of these compiler options are specified: `declaration`,
`declarationMap`, `emitDeclarationOnly`, `skipLibCheck`, `target`,
`paths`
4. all references to other packages/plugins use their pkg id, ie:
```js
// valid
{
"kbn_references": ["@kbn/core"]
}
// not valid
{
"kbn_references": [{ "path": "../../../src/core/tsconfig.json" }]
}
```
5. only packages/plugins which are imported somewhere in the ts code are
listed in `kbn_references`
This linter is not only validating all of the tsconfig.json files, but
it also will fix these config files to deal with just about any
violation that can be produced. Just run `node scripts/ts_project_linter
--fix` locally to apply these fixes, or let CI take care of
automatically fixing things and pushing the changes to your PR.
> **Example:** [`64e93e5`
(#146212)](64e93e5806)
When I merged main into my PR it included a change which removed the
`@kbn/core-injected-metadata-browser` package. After resolving the
conflicts I missed a few tsconfig files which included references to the
now removed package. The TS Project Linter identified that these
references were removed from the code and pushed a change to the PR to
remove them from the tsconfig.json files.
## No bazel? Does that mean no packages??
Nope! We're still doing packages but we're pretty sure now that we won't
be using Bazel to accomplish the 'distributed caching' and 'change-based
tasks' portions of the packages project.
This PR actually makes packages much easier to work with and will be
followed up with the bundling benefits described by the original
packages RFC. Then we'll work on documentation and advocacy for using
packages for any and all new code.
We're pretty confident that implementing distributed caching and
change-based tasks will be necessary in the future, but because of
recent improvements in the repo we think we can live without them for
**at least** a year.
## Wait, there are still BUILD.bazel files in the repo
Yes, there are still three webpack bundles which are built by Bazel: the
`@kbn/ui-shared-deps-npm` DLL, `@kbn/ui-shared-deps-src` externals, and
the `@kbn/monaco` workers. These three webpack bundles are still created
during bootstrap and remotely cached using bazel. The next phase of this
project is to figure out how to get the package bundling features
described in the RFC with the current optimizer, and we expect these
bundles to go away then. Until then any package that is used in those
three bundles still needs to have a BUILD.bazel file so that they can be
referenced by the remaining webpack builds.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
* Removed file-type from package.json deps.
Updated jimp to 0.16.1.
Updated light & dark dashboard baseline screenshots to resolve failure due to resize degradation.
* Replaced jimp with sharp and pixelmatch. Eliminates several deps, including file-type.
Eliminates quality degradation from image resizing.
* Fixed copy paste error, which lead to pass positives and errors.
* Integrated updateBaselines flag into dashboards report testing.
Fixed sharp resize to fit and not truncate the original image.
* Removed accidental '.only'
* Reverted area chart baseline.
* Removed explicit declaration of sharp from package.json.
* Adjusted dashboard screenshot size in attempt to eliminate layout scaling issues in CI testing.
* Reverted dashboard screenshot size. Lowered tolerance in dashboard PNG reporting tests to force failure and collect CI screenshots.
* Changed session save location for dashboard report images for better CI reporting.
* Fixed small dashboard baseline screenshot with correct aspect ratio.
* Updated 2 basline screenshots from CI. Lowered PNG match tolerance for dashboard screenshots to 1% for investigation of remaining screens.
* Update of dashboard controls light mode baseline.
Change of forced container width size in large dashboard layout test.
* Updated dashboard controls dark mode baseline screenshot.
Adjusted forced container width in large dashboard layout test for troubleshooting.
* Lowering tolerance of PNG compare tests from 9% to 1% for troubleshooting.
Replaced references to dedundant image service with existing, more adopted reporting service.
Ideally, the PNG functions of the reporting service would be merged with the screenshot service as an image service.
* Reverting tolerance of PNG compares to 0.09. Will create GH issues for specific teams to investigate.
* Implemented PngService to provide an accessible single reference to PNG compare testing.
Removed redundant implementations and references.
* Updated service reference and call to png compare function left out of last commit.
* Updated another missed PNG reference.
* Removed superfluous parameter.
* Update after bootstrap
* Updated area chart baseline to match new render with panel filters.
* Reverted limits in dashboard snapshot tests to original values.
* Merge and rebuild.
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* [ts] enable sourcemaps in summarized types of @kbn/crypto
* update snapshots
* remove unnecessary exports of @kbn/type-summarizer package
* remove tsc from the build process
* use `@kbn/type-summarizer` to summarize its own types
* add tests for interface and function
* switch to export type where necessary
* ignore __tmp__ in global jest preset
* ignore __tmp__ globally
* remove `@kbn/crypto` types path
* Support installing bundled packages during Fleet setup
* Fix failing API integration test
* Sort packages in test
* Move get bundled packages + add tests
* Fix mock installPackage type
* Don't attempt to install already-installed bundled packageS
* Use unique installation status for bundled packages
* Fix failing tests
* Fix type error
* Fix logic for latest value
* Remove bundled packages from test since they no longer come back from list endpoint
* Change assertion for empty preconfiguration update request
* Add all bundled packages + refactor install to use Promise.allSettled
* Fix name comparison again
* Rework approach to use preferred source at install-time instead
* Add helper script + update bundled packages + allow updates for upload path
* Fix failing test
* Address code review + add additional tests for update cases
* Fix type error
* Remove configOverride concept for now
* Fix another type error 🙃
* Add build step for bundling fleet packages
* Fix unused import in build step
* Keep bundled_packages directory in place to prevent setup failures
* Remove gitkeep + make bundled package directory lookup fault tolerant
* Update gitignore
* Add doc comment + use build.resolvePath
* Add --use-snapshot-registry CLI flag
* Update snapshots
* Rename arg to use-snapshot-epr
* Don't fail the build on failure to bundled packages
* Update all checksums + don't attempt download multiple times
* Skip checksum process for bundled packages for now
* mkdirp destination directory to fix tests
* Revert build_distributables file
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
