## Summary
In the past months, the capture OAS snapshot step has been quite flaky,
breaking the `Checks` step, and thus breaking the `on-merge` jobs.
This PR extracts the check to its own step and adds retries. The
separate step is ideal because it is quite heavy compared to the other
checks (we fire up ES + Kibana for the OAS snapshot).
Also, this PR removes the `Checks` step altogether from the
kibana-chrome-forward-testing pipeline, as the Chrome versions used do
not affect that aspect.
This test run includes a retry within the Capture OAS Snapshot step:
https://buildkite.com/elastic/kibana-pull-request/builds/243187#01929612-dac7-4584-b440-120ea3fea7ea
## Summary
This is Part 1 of the in resolving the issue :
https://github.com/elastic/kibana/issues/183645 .
This PR re-organizes investigations API tests so that they can be run in
Serveless MKI at both `basic/essentials` and `complete` licenses.
## How to test this PR
Below are the commands that are affected by this change and you can test
the PR by running below commands.
Each commands sets up the test environment and give you a command to run
tests. Please run those tests to see if everything is okay. An example
is shown in below screenshot.
<img width="1916" alt="grafik"
src="https://github.com/user-attachments/assets/fa400450-e4aa-41dc-a1ea-ac21634c46d3">
|Module|Deployment|License|Command|
|--|--|--|--|
|Timelines|ESS|basic|`yarn investigations:basic:timeline:server:ess`|
|Timelines|ESS|Trial|`yarn investigations:timeline:server:ess`|
|Timelines|Serverless|basic|`yarn
investigations:basic:timeline:server:serverless`|
|Timelines|Serverless|Trial|`yarn
investigations:timeline:server:serverless`|
|Saved Objects|ESS|basic|`yarn
investigations:basic:saved-objects:server:ess`|
|Saved Objects|ESS|Trial|`yarn investigations:saved-objects:server:ess`|
|Saved Objects|Serverless|basic|`yarn
investigations:basic:saved-objects:server:serverless`|
|Saved Objects|Serverless|Trial|`yarn
investigations:saved-objects:server:serverless`|
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This change is the implementation of the `Kibana Privilege Migrations`
proposal/RFC and provides a framework that allows developers to replace
an existing feature with a new one that has the desired configuration
while teaching the platform how the privileges of the deprecated feature
can be represented by non-deprecated ones. This approach avoids
introducing breaking changes for users who still rely on the deprecated
privileges in their existing roles and any automation.
Among the use cases the framework is supposed to handle, the most common
are the following:
* Changing a feature ID from `Alpha` to `Beta`
* Splitting a feature `Alpha` into two features, `Beta` and `Gamma`
* Moving a capability between privileges within a feature (top-level or
sub-feature)
* Consolidating capabilities across independent features
## Scope
This PR includes only the core functionality proposed in the RFC and
most of the necessary guardrails (tests, early validations, etc.) to
help engineers start planning and implementing their migrations as soon
as possible. The following functionality will be added in follow-ups or
once we collect enough feedback:
* Telemetry
* Developer documentation
* UI enhancements (highlighting roles with deprecated privileges and
manual migration actions)
## Framework
The steps below use a scenario where a feature `Alpha` should be split
into two other features `Beta` and `Gamma` as an example.
### Step 1: Create new features with the desired privileges
First of all, define new feature or features with the desired
configuration as you'd do before. There are no constraints here.
<details>
<summary>Click to see the code</summary>
```ts
deps.features.registerKibanaFeature({
id: 'feature_beta',
name: 'Feature Beta',
privileges: {
all: {
savedObject: { all: ['saved_object_1'], read: [] },
ui: ['ui_all'],
api: ['api_all'],
… omitted for brevity …
},
read: {
savedObject: { all: [], read: ['saved_object_1'] },
ui: ['ui_read'],
api: ['api_read'],
… omitted for brevity …
},
},
… omitted for brevity …
});
deps.features.registerKibanaFeature({
id: 'feature_gamma',
name: 'Feature Gamma',
privileges: {
all: {
savedObject: { all: ['saved_object_2'], read: [] },
ui: ['ui_all'],
// Note that Feature Gamma, unlike Features Alpha and Beta doesn't provide any API access tags
… omitted for brevity …
},
read: {
savedObject: { all: [], read: ['saved_object_2'] },
ui: ['ui_read'],
// Note that Feature Gamma, unlike Features Alpha and Beta doesn't provide any API access tags
… omitted for brevity …
},
},
… omitted for brevity …
});
```
</details>
### Step 2: Mark existing feature as deprecated
Once a feature is marked as deprecated, it should essentially be treated
as frozen for backward compatibility reasons. Deprecated features will
no longer be available through the Kibana role management UI and will be
replaced with non-deprecated privileges.
Deprecated privileges will still be accepted if the role is created or
updated via the Kibana role management APIs to avoid disrupting existing
user automation.
To avoid breaking existing roles that reference privileges provided by
the deprecated features, Kibana will continue registering these
privileges as Elasticsearch application privileges.
<details>
<summary>Click to see the code</summary>
```ts
deps.features.registerKibanaFeature({
// This is a new `KibanaFeature` property available during feature registration.
deprecated: {
// User-facing justification for privilege deprecation that we can display
// to the user when we ask them to perform role migration.
notice: i18n.translate('xpack.security...', {
defaultMessage: "Feature Alpha is deprecated, refer to {link}...",
values: { link: docLinks.links.security.deprecatedFeatureAlpha },
})
},
// Feature id should stay unchanged, and it's not possible to reuse it.
id: 'feature_alpha',
name: 'Feature Alpha (DEPRECATED)',
privileges: {
all: {
savedObject: { all: ['saved_object_1', 'saved_object_2'], read: [] },
ui: ['ui_all'],
api: ['api_all'],
… omitted for brevity …
},
read: {
savedObject: { all: [], read: ['saved_object_1', 'saved_object_2'] },
ui: ['ui_read'],
api: ['api_read'],
… omitted for brevity …
},
},
… omitted for brevity …
});
```
</details>
### Step 3: Map deprecated feature’s privileges to the privileges of the
non-deprecated features
The important requirement for a successful migration from a deprecated
feature to a new feature or features is that it should be possible to
express **any combination** of the deprecated feature and sub-feature
privileges with the feature or sub-feature privileges of non-deprecated
features. This way, while editing a role with deprecated feature
privileges in the UI, the admin will be interacting with new privileges
as if they were creating a new role from scratch, maintaining
consistency.
The relationship between the privileges of the deprecated feature and
the privileges of the features that are supposed to replace them is
expressed with a new `replacedBy` property available on the privileges
of the deprecated feature.
<details>
<summary>Click to see the code</summary>
```ts
deps.features.registerKibanaFeature({
// This is a new `KibanaFeature` property available during feature registration.
deprecated: {
// User-facing justification for privilege deprecation that we can display
// to the user when we ask them to perform role migration.
notice: i18n.translate('xpack.security...', {
defaultMessage: "Feature Alpha is deprecated, refer to {link}...",
values: { link: docLinks.links.security.deprecatedFeatureAlpha },
})
},
// Feature id should stay unchanged, and it's not possible to reuse it.
id: 'feature_alpha',
name: 'Feature Alpha (DEPRECATED)',
privileges: {
all: {
savedObject: { all: ['saved_object_1', 'saved_object_2'], read: [] },
ui: ['ui_all'],
api: ['api_all'],
replacedBy: [
{ feature: 'feature_beta', privileges: ['all'] },
{ feature: 'feature_gamma', privileges: ['all'] },
],
… omitted for brevity …
},
read: {
savedObject: { all: [], read: ['saved_object_1', 'saved_object_2'] },
ui: ['ui_read'],
api: ['api_read'],
replacedBy: [
{ feature: 'feature_beta', privileges: ['read'] },
{ feature: 'feature_gamma', privileges: ['read'] },
],
… omitted for brevity …
},
},
… omitted for brevity …
});
```
</details>
### Step 4: Adjust the code to rely only on new, non-deprecated features
Special care should be taken if the replacement privileges cannot reuse
the API access tags from the deprecated privileges and introduce new
tags that will be applied to the same API endpoints. In this case,
developers should replace the API access tags of the deprecated
privileges with the corresponding tags provided by the replacement
privileges. This is necessary because API endpoints can only be accessed
if the user privileges cover all the tags listed in the API endpoint
definition, and without these changes, existing roles referencing
deprecated privileges won’t be able to access those endpoints.
The UI capabilities are handled slightly differently because they are
always prefixed with the feature ID. When migrating to new features with
new IDs, the code that interacts with UI capabilities will be updated to
use these new feature IDs.
<details>
<summary>Click to see the code</summary>
```ts
// BEFORE deprecation/migration
// 1. Feature Alpha defition (not deprecated yet)
deps.features.registerKibanaFeature({
id: 'feature_alpha',
privileges: {
all: {
api: ['api_all'],
… omitted for brevity …
},
},
… omitted for brevity …
});
// 2. Route protected by `all` privilege of the Feature Alpha
router.post(
{ path: '/api/domain/my_api', options: { tags: ['access:api_all'] } },
async (_context, request, response) => {}
);
// AFTER deprecation/migration
// 1. Feature Alpha defition (deprecated, with updated API tags)
deps.features.registerKibanaFeature({
deprecated: …,
id: 'feature_alpha',
privileges: {
all: {
api: ['api_all_v2'],
replacedBy: [
{ feature: 'feature_beta', privileges: ['all'] },
],
… omitted for brevity …
},
},
… omitted for brevity …
});
// 2. Feature Beta defition (new)
deps.features.registerKibanaFeature({
id: 'feature_beta',
privileges: {
all: {
api: ['api_all_v2'],
… omitted for brevity …
}
},
… omitted for brevity …
});
// 3. Route protected by `all` privilege of the Feature Alpha OR Feature Beta
router.post(
{ path: '/api/domain/my_api', options: { tags: ['access:api_all_v2'] } },
async (_context, request, response) => {}
);
----
// ❌ Old client-side code (supports only deprecated privileges)
if (capabilities.feature_alpha.ui_all) {
… omitted for brevity …
}
// ✅ New client-side code (will work for **both** new and deprecated privileges)
if (capabilities.feature_beta.ui_all) {
… omitted for brevity …
}
```
</details>
## How to test
The code introduces a set of API integration tests that are designed to
validate whether the privilege mapping between deprecated and
replacement privileges maintains backward compatibility.
You can run the test server with the following config to register a
number of [example deprecated
features](https://github.com/elastic/kibana/pull/186800/files#diff-d887981d43bbe30cda039340b906b0fa7649ba80230be4de8eda326036f10f6fR20-R49)(`x-pack/test/security_api_integration/plugins/features_provider/server/index.ts`)
and the features that replace them, to see the framework in action:
```bash
node scripts/functional_tests_server.js --config x-pack/test/security_api_integration/features.config.ts
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This is a build/promotion system change only, there is no code related
changes here.
- Similar to https://github.com/elastic/kibana/pull/195944, but for the
non-emergency pipeline in staging
- For now, only run the staging manual judgement on slice:
'staging-ds-2'
- Since slices can be grouped as a comma delimited list, we're choosing
to be overly cautious with the regex
## Summary
Closes https://github.com/elastic/kibana/issues/193703
This PR introduces a callout designed to prompt users to ingest metrics
data in the Host and Container views.
The callout will be displayed on the following tabs:
- **Hosts**: Overview, Metrics, Processes
- **Containers**: Overview, Metrics
The primary condition for showing the callout is that the asset does not
currently have any metrics data available. This enhancement aims to
encourage users to take action and improve their monitoring experience.
Additional details include:
- The callout will be positioned below the date picker for better
visibility.
- Links for "Add Metrics" will guide users to the appropriate onboarding
pages based on their asset type.
- The callout will be dismissible on the Overview tab, and the KPI
section will be hidden in favor of the callout for a cleaner interface.
- Custom telemetry events will be tracked to measure user interactions
with the callout.
- Only Docker and K8 containers will show the callout.
**Host**
|Tab||
|-|-|
|Overview||
|Metrics||
|Processes||
**Container**
|Tab||
|-|-|
|Overview||
|Metrics||
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Caue Marcondes <caue.marcondes@elastic.co>
This is a build/promotion system change only, there is no code related
changes here.
- For now, only run the staging manual judgement on slice:
'staging-ds-2'
- Since slices can be grouped as a comma delimited list, we're choosing
to be overly cautious with the regex
## Summary
We've added a new pipeline in #195581, where the name update wasn't
synced to the PR configuration, so the new button is looking for a
non-existent pipeline.
This PR updates the target
## Summary
This PR re-enables the serverless deployment agnostic tests
### Details
- The root cause of the problem should be fixed with #195563
- This reverts commit 8d1bc50335Closes#195811
## Summary
There's a use-case where developers would like to work while testing
their deployments in a serverless environment, or they'd like to
redeploy only, without running the whole suite of tests before. Labels
are still required because project deployment requires the project kind
to be prescribed.
This PR adds the instruments to do so:
- pipeline resource definition to create a new pipeline
- pipeline implementation, that only builds and deploys
- `pull-requests.json` configuration, so the option shows up in the
'click to xy' section
With this, we present a cheaper, faster way to deploy serverless when
needed.
Closes: https://github.com/elastic/kibana-operations/issues/121
---------
Co-authored-by: Brad White <Ikuni17@users.noreply.github.com>
1) After an elasticsearch image is promoted, this triggers a VM rebuild
to update the snapshot cache
1) Moves elasticsearch builds to later in the day, when there's less
activity.
## Summary
This PR tags all pipelines that are related to the Kibana serverless
release (including requirements like on-merge and artifacts build) with
`kibana-serverless-release`. This will allow us to easily find these
pipelines in Buildkite.
## Summary
Adding `functional_search` suite with a set of test for the search
solution navigation. But this suite will also grow to test search
solution pages that do not require the enterprise search node.
### Checklist
- [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
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
## Summary
Kibana-related pipelines are hard to find on Buildkite, due to other,
ingest-related pipelines having 'kibana' in their names.
This pipeline adds tags to pipelines serving `kibana` CI duties, so they
can be easily found using Buildkite's tags/labels.
The tags added are mostly `kibana` but some pipelines also got the
`security-solution` label, as these pipelines can be easily associated
with the served solution.
## Summary
Added in #194682, this pipeline is failing, because we were reusing the
PR pipeline, that at some parts expect PR-related env-vars to be around.
This PR introduces a new pipeline implementation, so we're no longer
sharing the pipeline with the PR jobs. This prevents errors coming from
assuming there are relative changes in the context.
The PR also propagates the `USE_CHROME_BETA` flag to the cypress runners
of the security solution scripts (I've noticed most other pipelines rely
on these runners).
This run demonstrates the pipeline:
https://buildkite.com/elastic/kibana-chrome-forward-testing/builds/9
https://github.com/elastic/kibana/pull/194768 without the merge
conflicts.
Switches over to the org wide PR bot, with backwards compatibility for
both versions.
Updating the pipeline definition here is a global set for environment
variables on all branches, so I intend on merging the backports first to
support both versions and then proceeding with this.
## Summary
Closes https://github.com/elastic/kibana/issues/184685
**Release notes**: These schema changes shouldn't be breaking, but there
were some incorrect/missing response schemas in the old openapi spec.
For example the API `POST /api/fleet/agents/{agentId}/actions` response
was incorrectly documented:
https://petstore.swagger.io/?url=https://raw.githubusercontent.com/elastic/kibana/main/x-pack/plugins/fleet/common/openapi/bundled.json#/Elastic%20Agent%20actions/new-agent-action
```
{
"body": [
0
],
"statusCode": 0,
"headers": "string"
}
```
Fixed here:
31f8cfd6ef/oas_docs/bundle.json#/Elastic%20Agent%20actions/%252Fapi%252Ffleet%252Fagents%252F%257BagentId%257D%252Factions%230
```
{
"item": {
"ack_data": "string",
"agents": [
"string"
],
"created_at": "string",
"data": "string",
"expiration": "string",
"id": "string",
"minimum_execution_duration": 0,
"namespaces": [
"string"
],
"rollout_duration_seconds": 0,
"sent_at": "string",
"source_uri": "string",
"start_time": "string",
"total": 0,
"type": "string"
}
}
```
The new spec should match the implementation accurately, and responses
are being verified when returned. Tests were added to make sure the
response schemas are correct.
If there are any bugs in the current schema, it will result in a HTTP
500 error with an error message on where the schema validation failed.
Example of an error where a field is missing:
```
{
"statusCode": 500,
"error": "Internal Server Error",
"message": "Failed output validation: [request body.items.0.name]: definition for this key is missing"
}
```
Example of an error where a field is mandatory in the schema, but not
provided in the response (missing `schema.maybe`)
```
{
"statusCode": 500,
"error": "Internal Server Error",
"message": "Failed output validation: [request body.items.0.internal]: expected value of type [boolean] but got [undefined]"
}
```
There are a few places where the validation allows unknown fields. Used
it where some fields were not included in TS types or fields are more
dynamic, e.g. fields coming from packages or elasticsearch settings.
https://github.com/search?q=repo%3Aelastic%2Fkibana+extendsDeep+path%3A%2F%5Ex-pack%5C%2Fplugins%5C%2Ffleet%5C%2Fserver%5C%2Ftypes%5C%2F%2F&type=code
```
.extendsDeep({
unknowns: 'allow',
})
```
Changes in this pr:
Remove using old `bundled.yaml` to generate oas, fixed tags.
Removed old openapi files, updated readme.
Here is the new bundle in Swagger UI:
[stateful](31f8cfd6ef/oas_docs/bundle.json)
[serverless](da72ee0093/oas_docs/bundle.serverless.json)
Updated serverless scripts too.
Updated Fleet readme:
da72ee0093/x-pack/plugins/fleet/common/openapi/README.md
Generated the new bundle by running this script locally:
```
node scripts/capture_oas_snapshot --include-path /api/fleet --update
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Creates a pipeline for testing against `google-chrome-beta`.
- Uses the flag: `USE_CHROME_BETA` to switch functional tests to running
against chrome-beta.
- Uses the same pipeline file PR builds are using
- Only FTRs will be using `google-chrome-beta`, so other test types are
disabled
- [x] check if other test types (integration / cypress) can be directed
to `google-chrome-beta`.
Tested with the migration staging pipeline:
https://buildkite.com/elastic/kibana-migration-pipeline-staging/builds/164
Connected to: https://github.com/elastic/kibana-operations/issues/199
Closes#192153
## Summary
This PR sets the spaces and roles CRUD operation HTTP API endpoints to
public in both stateful and serverless offerings, and additionally,
switches to the versioned router to register these endpoints.
Prior to this PR, the access level was not explicitly set, thus any
endpoints registered in serverless were by default internal. CRUD
operations for spaces and roles are being set to public to support the
rollout of custom roles in serverless, which coincides with enabling
multiple spaces.
### Note
- Currently, roles APIs are only available in serverless via a feature
flag (`xpack.security.roleManagementEnabled`)
- Spaces APIs are already registered in serverless, however, the maximum
number of spaces is by default 1, rendering create and delete operations
unusable. By overriding `xpack.spaces.maxSpaces` to a number greater
than 1 (stateful default is 1000), it will effectively enable use of the
spaces CRUD operations in serverless.
## Tests
-
x-pack/test_serverless/api_integration/test_suites/common/management/multiple_spaces_enabled.ts
-
x-pack/test_serverless/api_integration/test_suites/common/management/spaces.ts
-
x-pack/test_serverless/api_integration/test_suites/common/platform_security/authorization.ts
-
x-pack/test_serverless/api_integration/test_suites/common/platform_security/roles_routes_feature_flag.ts
- Unit tests for each endpoint (to account for versioned router)
- Flaky Test Runner:
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7002
## Manual Testing
1. Start ES & Kibana in serverless mode with config options to enable
role management and multiple spaces
Elasticsearch:
```
xpack.security.authc.native_roles.enabled: true
```
KIbana:
```
xpack.security.roleManagementEnabled: true
xpack.spaces.maxSpaces: 100
```
3. Issue each CRUD HTTP API without including the internal origin header
('x-elastic-internal-origin') and verify you do not receive a 400 with
the message "method [get|post|put|delete] exists but is not available
with the current configuration"
4. Repeat steps 1 & 2 from the current head of main and verify that you
DO receive a 400 with the message "method [get|post|put|delete] exists
but is not available with the current configuration"
Regression testing - ensure that interfaces which leverage spaces and
roles APIs are functioning properly
- Spaces management
- Space navigation
- Roles management
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Close https://github.com/elastic/kibana-team/issues/1017
This PR removes the unused Cloud Chat functionality from Kibana. The
chat was not used for some time. Moreover, we've seen some issues with
it where users saw it when it wasn't expected. Given the absence of
automated tests and the fact that the feature is no longer needed, we
are removing it to improve the overall maintainability and reliability
of the codebase. This will also decrease the amount of code loaded for
trial users of Kibana in cloud making the app slightly faster.
## Summary
Updates the web logs journey to use Lens charts instead of deprecated
ones. Specifically there was one TSVB and one goal that got replaced.
Also there were 3 legacy metric Lens visualizations. I updated them to
use the lens metric type
## Summary
Renames the text-based-editor to esql-editor
I tried to also rename components, data-test-subj, classNames and files.
My focus is mostly on the plugin and package of the esql editor
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/182548
Creates an dashboard journey similar to the web logs one but the
majority of the visualizations are using ES|QL.
Note: There is one Lens viz not converted yet because it needs
inlinestats. We could also convert it when inlinestats go to GA.
This PR introduces the following API routes for listing Entity Store
"entities":
<meta charset="utf-8"><b style="font-weight:normal;"
id="docs-internal-guid-9410c5d7-7fff-e873-6830-887939a306fb"><div
dir="ltr" style="margin-left:-0.75pt;" align="left">
List Entities | GET /api/entity_store/entities/list
-- | --
</div></b>
The PR includes the following:
- The OpenAPI schemas for the route
- The actual Kibana side endpoint
- Add searchEntities function to the `EntityStoreDataClient`
### How to test
1. Add some host/user data
* Easiest is to use
[elastic/security-data-generator](https://github.com/elastic/security-documents-generator)
2. Make sure to add `entityStoreEnabled` under
`xpack.securitySolution.enableExperimental` in your `kibana.dev.yml`
3. In kibana dev tools or your terminal, call the `INIT` route for
either `user` or `host`.
4. You should now see 2 transforms in kibana. Make sure to re-trigger
them if needed so they process the documents.
5. Call the new API, and it should return entities
Implements https://github.com/elastic/security-team/issues/10517
### Checklist
- [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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Updated `js-yaml` to `4.1.0`.
This PR also introduces a type override for the `js-yaml` load function
to maintain compatibility across the codebase. Specifically, updated
type definition of the load function looks as follows:
```typescript
function load<T = any>(str: string, opts?: jsyaml.LoadOptions): T;
```
The original type definition of the load function in `js-yaml` changed
from `any` to `unknown`. This change would require extensive type
updates throughout the entire repository to accommodate the `unknown`
type. To avoid widespread type changes and potential issues in the
codebase, the type is overriden back to `any` for now.
This is a temporary measure, we plan to address the necessary type
changes in subsequent PRs, where teams will gradually update the
codebase to work with the `unknown` type.
### Checklist
- [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
## Release note
Updated `js-yaml` to `4.1.0`.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Maxim Palenov <maxim.palenov@elastic.co>
## Summary
It’s common request for Dev teams to run specific journeys on a PR to
compare performance metrics against the `main` branch. These requests
usually focus on a particular area, such as the Dashboard or Discover
app.
To streamline the process, this PR groups relevant journeys into
categories that can be triggered through an environment variable. For
example, setting `JOURNEYS_GROUP=dashboard` will execute only the three
dashboard-specific journeys, which are (usually) sufficient for
evaluating the performance impact of code changes within the Dashboard
app.
Current Process for Triggering Performance Builds:
- Create a new kibana-single-user-performance
[build](https://buildkite.com/elastic/kibana-single-user-performance#new)
- Provide the following arguments:
Branch: `refs/pull/<PR_number>/head`
Under Options, set the environment variable:
`JOURNEYS_GROUP=<group_name>`
Currently supported journey groups:
- kibanaStartAndLoad
- crud
- dashboard
- discover
- maps
- ml
[Build example
](https://buildkite.com/elastic/kibana-single-user-performance/builds/14427)
Each group focuses on a specific set of journeys tied to its respective
area in Kibana, allowing for more targeted performance testing. Since
running group takes ~5-10 min on bare metal worker, it should not delay
the regular (every 3h) runs against `main` branch
test locally with `node scripts/run_performance.js --group <group_name>`
Part of https://github.com/elastic/kibana/issues/192005
Closes https://github.com/elastic/kibana/issues/176533
## Summary
This PR represents the first major cleanup task for the control group
embeddable refactor. The tasks included in this PR can be loosely
summarized as follows:
1. This PR removes the old, non-React version of controls
- Note that the new controls are still included under the
`react_controls` folder - I will address this in a follow up PR.
2. This PR removes **all** types associated with the old embeddable
system; i.e. any `*input*` or `*output*` types.
- As part of cleaning up these types, some of the types included in the
`public/react_controls` folder had to be moved to `common` to make them
available to server-side code.
- This resulted in an... unfortunate number of import changes 🫠 Hence
the rather large file change count. I took this opportunity to organize
the imports, too - so a significant chunk of these files are simply
import changes.
3. This PR removes the controls Storybook and all related mocks
- Since the controls storybooks have been broken for awhile, and since
we had plans to remove them but never got around to it, I just decided
to delete them as part of this PR and close
https://github.com/elastic/kibana/issues/176533 rather than spending
time to fix the types for non-operational stories
### Checklist
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [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
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
