**!!MAJORITY OF THE CHANGED FILES ARE MOVED OR COPIED!!**
### Vision
According to the product vision we will build a new simple UI/UX in the
future https://github.com/elastic/security-team/issues/11790
This PR is a first iteration on enabling Content Connectors Management
UI in Serverless Kibana Stack Management.
Elastic Managed content connectors will be available only for Security
and Observability projects.
### Current PR scope
1. Used initial search_connectors plugin and renamed it to
content_connectors + moved from `x-pack/solutions/search` to
`x-pack/platform/plugins/shared`
2. Copy relevant connectors UI and routes from enterprise_search plugin.
3. Introduce the new Stack Management card/navigation option under the
Data section.
4. Enabled this plugin only in Serverless for Security and Observability
projects.
5. For making PR smaller Pipelines tab was not moved. And according to
Search team vision this functionality should be dropped anyway soon.
6. Extended fleet package logic to include elastic_connectors for
security and o11y serverless projects
7. Added back `search:agentless-connectors-manager` task
In Stack Management navigation:
<img width="2062" alt="Screenshot 2025-04-15 at 3 51 43 PM"
src="https://github.com/user-attachments/assets/5c93ba01-9a6a-4eac-a21d-1370f03b8f35"
/>
Stack Management cards:
<img width="2081" alt="Screenshot 2025-04-10 at 8 41 43 PM"
src="https://github.com/user-attachments/assets/3def1c12-561b-4a84-8241-4dd61cd9313d"
/>
Create Elastic Managed Connector UI (on Agentless):
<img width="1822" alt="Screenshot 2025-04-15 at 3 55 29 PM"
src="https://github.com/user-attachments/assets/6e9fea48-85e7-43df-919d-0e5492d0e704"
/>
Create Self Managed Connector UI:
<img width="2064" alt="Screenshot 2025-04-15 at 3 55 49 PM"
src="https://github.com/user-attachments/assets/d5051898-c8fa-4e41-b9ea-b41d4ed4a0d5"
/>
### Next steps
- [ ] Remove duplicated code between content_connectors,
enterprise_search and serverless_search
- [ ] Extract [common server
libs](https://github.com/elastic/kibana/tree/main/x-pack/solutions/search/plugins/enterprise_search/server/lib)
to the shared package `kbn-search-connectors`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Steph Milovic <stephanie.milovic@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Artem Shelkovnikov <artem.shelkovnikov@elastic.co>
Co-authored-by: Artem Shelkovnikov <lavatroublebubble@gmail.com>
Co-authored-by: Kyle Pollich <kyle.pollich@elastic.co>
## Summary
Implements the alerts filters form that will be used to pre-filter the
alerts table embeddable.
<img width="1004" alt="image"
src="https://github.com/user-attachments/assets/b51ce051-40d2-42d0-a9c1-0fba3fd919af"
/>
> [!NOTE]
> I'm using the terminology "form" to distinguish this from the alert
filter _controls_ or other type of more KQL-bar-like filters. Other
alternatives that came to mind were `alerts-boolean-filters-...` or
`alerts-filters-builder`.
<details>
<summary>
## Implementation details
</summary>
### Filters expression state
I opted for a tree state representation of the form's boolean expression
to accommodate potential future requirements such as more complex
boolean expressions (negation, parenthesized subexpressions to manually
control operators precedence):
```ts
{
operator: 'or',
operands: [
{
operator: 'or',
operands: [
{ type: 'ruleTags', value: ['tag-1'] },
{ type: 'ruleTags', value: ['tag-2'] },
{
operator: 'and',
operands: [{ type: 'ruleTypes', value: ['type-1'] }, { type: 'ruleTypes', value: ['type-2'] }],
},
],
},
{ type: 'ruleTags', value: ['tag-3'] },
],
}
```
This state is saved in the embeddable panel state and represents the
editor form. The embeddable alerts table wrapper component will then
transform this to an actual ES query.
To simplify interactions inside the form, an intermediate equivalent
flattened state is used:
```ts
[
{ filter: { type: 'ruleTags', value: ['tag-1'] } },
{ operator: 'or' },
{ filter: { type: 'ruleTags', value: ['tag-2'] } },
{ operator: 'or' },
{ filter: { type: 'ruleTypes', value: ['type-1'] }},
{ operator: 'and' },
{ filter: { type: 'ruleTypes', value: ['type-2'] } },
{ operator: 'or' },
{ filter: { type: 'ruleTags', value: ['tag-3'] } },
]
```
### Filters model
Each filter is described by an `AlertsFilterMetadata<T>` object, where
`T` is the type of the filter value:
```tsx
export const filterMetadata: AlertsFilterMetadata<string[]> = {
id: 'ruleTags',
displayName: RULE_TAGS_FILTER_LABEL,
component: AlertsFilterByRuleTags,
// Filter-specific empty check
isEmpty: (value?: string[]) => !value?.length,
// Conversion to ES query DSL
toEsQuery: (value: string[]) => {
return {
terms: {
[ALERT_RULE_TAGS]: value,
},
};
},
};
```
</details>
## Verification steps
1. Run Kibana with examples (`yarn start --run-examples`)
2. Create rules in different solutions with tags
3. Navigate to `/app/triggersActionsUiExample/alerts_filters_form`
4. Check that the solution selector options are coherent with the rule
types the user can access
5. Select a solution
6. Build filters expressions, checking that the rule tags and rule types
are coherent with the solution selection and the rules created
previously
7. Repeat steps 3-6 with different roles:
7.1. having access to rule types from just one solution (in this case
the solution selector shouldn't appear at all),
7.2. having access just to Observability and Stack but not Security (in
this case the solution selector shouldn't appear at all),
8. Repeat steps 3-6 in the three serverless project types:
```shell
$ yarn es serverless —ssl --projectType <es|oblt|security>
$ yarn serverless-<es|oblt|security> --ssl --run-examples
```
(If the authentication fails when switching between project types, use a
clean session)
8.1. ES project types should have access only to Stack rules (no
selector)
8.2. Observability project types should have access only to
Observability and Stack rules (no selector)
8.3. Security project types should have access only to Security and
Stack rules (selector shows Stack instead of Observability)
## References
Depends on #214187Closes#213061
### 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/src/platform/packages/shared/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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Christos Nasikas <xristosnasikas@gmail.com>
## Summary
Pre-requisite for https://github.com/elastic/kibana/pull/216088, as the
`AI Assistant Management` configuration settings should be available for
Search too.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Removes unused code from the Investigate and Investigate app plugin.
Removes all references to those plugins in storybook, i18n, types, etc.
Removes codeowner requirements for those plugins
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/214446
This PR introduces a new section in the span/transaction overview flyout
that will display the duration information along with a latency chart.
For now, only the duration data is included.
|Scenario||
|-|-|
|Span w/ `transaction.id`||
|Span w/o `transaction.id`||
|Transaction w/ `parent.id`||
|Transaction w/o `parent.id` (root transaction)||
Given that both spans and transactions require retrieving data from
their respective parents, a loader has been added to reflect the ongoing
data-fetching process:
## Tech details
The UI for displaying the duration and its percentage relative to the
parent is already in use in APM for spans and transactions, so the logic
is consistent with that.
To avoid duplicating components and formatters, as seen in previous PRs
for Traces in Discover, a new `Duration` component has been created in a
newly created `kbn-apm-ui-shared` package. This component will be used
in Discover and [later](https://github.com/elastic/kibana/issues/211781)
in APM as well.
## How to test
- Enable the discover profiles by adding this to the` kibana.yml `file:
```discover.experimental.enabledProfiles:
- observability-traces-data-source-profile
- observability-traces-transaction-document-profile
- observability-traces-span-document-profile
```
- Open Discover and select or create a data view that includes any APM
traces index (`traces-*`), or query them using ES|QL.
- Apply a filter for `data_stream.type:"traces"` to ensure only trace
documents are retrieved.
- Open the flyout.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Carlos Crespo <crespocarlos@users.noreply.github.com>
## Summary
Resolves: https://github.com/elastic/kibana/issues/190661
This PR allows tasks to be ran scoped as the current user. It
accomplishes this by creating an API when the user schedules this task.
It will then persist the API key in the task instance which allows the
task handler to have access to the user's privileges.
To test:
1. Run `yarn start --run-examples`
2. Navigate to
`http://localhost:5601/app/triggersActionsUiExample/task_manager_with_api_key`
3. Click on `Schedule Task 1 and 2`, this will schedule a mock test that
is defined in
`x-pack/platform/plugins/shared/alerting/server/plugin.ts`, which prints
out the task instance and the scoped clients.
4. Click on `Remove` to cancel the task, which then cleans up and
invalidates the API keys.
5. Reschedule the 2 tasks and click on `Remove All Tasks` which will
bulk remove tasks and invalidate API keys.
Limitation of this approach:
- Because we depend on a request, this would mean every schedule that is
tied to a user needs to be triggered using a request. (Unless we have a
way of generating an API key without using the request).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Bring in the changes from https://github.com/elastic/eui/pull/8304,
specifically ESLint rules:
- `no-restricted-eui-imports`
- `no-css-color` (migrated from `@kbn/eslint-plugin-css`)
- `prefer-css-attribute-for-eui-components` (migrated from
`@kbn/eslint-plugin-css`)
Relates to https://github.com/elastic/eui/issues/8201,
https://github.com/elastic/eui-private/issues/275
## QA
### Instructions
1. Checkout this branch: `gh pr checkout 210082`.
2. Reinstall dependencies: `yarn kbn bootstrap`.
3. See output of ESLint. There should be no errors.
4. Test below cases.
### Test cases
#### `no-restricted-eui-imports`
Example files:
- JSON imports: `src/platform/packages/shared/kbn-ui-theme/src/theme.ts`
- `@kbn/ui-theme`:
`src/platform/plugins/private/vis_types/vega/public/data_model/utils.ts`
#### `no-css-color`
Example file:
`src/platform/plugins/shared/kibana_react/public/page_template/no_data_page/no_data_card/elastic_agent_card.tsx:50`
#### `prefer-css-attribute-for-eui-components`
Example file:
`x-pack/examples/alerting_example/public/alert_types/always_firing.tsx:166`
## Summary
~**DO NOT MERGE:** depends on
https://github.com/elastic/kibana/issues/213468~
This PR reintegrates the work from the `workchat_m1` branch into `main`:
- introduces a 4th solution type, `chat`, that will be used for the
*WorkChat* project type.
- edit things in various platform code to introduce/handle that new
project type
- add plugins and packages for the workchat app.
### To AppEx reviewers:
File change count is scary, but you can safely ignore anything from
`xpack/solutions/chat` (given it's solution code), and focus on your
owned changes, which are way more reasonable
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Joe McElroy <joseph.mcelroy@elastic.co>
Co-authored-by: Rodney Norris <rodney.norris@elastic.co>
Co-authored-by: Jedr Blaszyk <jedrazb@gmail.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Meghan Murphy <meghan.murphy@elastic.co>
# @kbn/profiler-cli
Profile Kibana while it's running, and open the CPU profile in
Speedscope.
## Usage
Run a command by either preceding it with the profiler script:
`node scripts/profile.js -- $command`
Or by piping it in:
`$command | node scripts/profile.js`
You can also just run it until SIGINT:
`node scripts/profile.js`
Or with a timeout:
`node scripts/profile.js --timeout=10000`
## Examples
### Commands
You can copy a curl request from the browser, and place it after the
command:
`node scripts/profile.js --connections=10 --amount=50 -- curl ...`
You can also use stdin for this, for example:
`pbpaste | node scripts/profile.js`
When using stdin, take into consideration that there is some lag between
starting the script and connecting the profiler, so the profiler might
miss the first second or so of the running process.
You can also use any other command, like `autocannon`, `sleep` or
`xargs`.
### SigInt
By default, the profiler will run until the process exits:`node
scripts/profile.js`. This is useful when you have a long running process
running separately and you want to collect the profile over a longer
time period. Be aware that this might cause memory issues because the
profile will get huge. When you press Cmd+C, the profiler will
gracefully exit and first write the profile to disk and open Speedscope.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This adds an additional custom ESLint rule package which checks certain
Eui elements for the existence of an `aria-label` prop.
If it exists, it will leave it untouched. If it doesn't, it will warn
the engineer it needs to be added, and offers a autofix suggestion for
those engineers who have fix on save enabled in their IDE.
<img width="739" alt="Screenshot 2025-03-25 at 13 59 28"
src="https://github.com/user-attachments/assets/0813b317-c752-40d7-b569-e866a3ecf6b0"
/>
<img width="804" alt="Screenshot 2025-03-25 at 13 59 36"
src="https://github.com/user-attachments/assets/3c45c49c-6db8-4740-b5de-89aa534c248b"
/>
This package is an offshoot of the `kbn-eslint-plugin-i18n` and
`kbn-eslint-plugin-telemetry` packages.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
- Creates a `@kbn/response-ops-rules-apis` package, following the
proposed structure for ResponseOps Management Experiences package.
- Moves relevant rules API fetchers and react-query hooks to the new
package.
- Adds an internal variant of the `/api/alerting/rule_types` endpoint
(`/internal/alerting/_rule_types`), that returns the same value as the
public one + the newly added internal [`solution`
field](https://github.com/elastic/kibana/issues/212017), that we don't
want to expose publicly.
## Verification steps
1. Create rules that fire alerts
2. Verify the usages of the moved/changed hooks, with limited privileges
as well (i.e. only `Rules Settings` but not `Stack Rules`):
2.1. Stack management and Observability rules, rule details and alerts
pages
2.2. Rules tab in the Connector editor flyout
2.3. Alerts table row actions (••• icon)
2.4. Tags filter in the rules list page
3. Using the DevTools, compare the response of the public and internal
`rule_types` endpoins:
```
GET kbn:/api/alerting/rule_types
GET kbn:/internal/alerting/_rule_types
```
Checking that the `solution` field is present only in the internal one
## References
Closes#213059
### 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
Closes https://github.com/elastic/kibana/issues/210298
In this PR we are adding the initial structure for the
@kibana/scout-security package, note that this is not ready to be used
and any new test using this package, is not going to be executed as part
of the regular pipelines, meaning, you are not going to add coverage to
the application.
@kibana/scout-security package is a test package that extends @kbn/scout
with test helpers specifically designed to test Security Solution
functionalities in Kibana. All tests under Security plugins should only
import from @kbn/scout-security, not from @kbn/scout.
This PR is a POC to start testing development by providing custom
Playwright fixtures, page objects, and utilities tailored for
Security-related testing scenarios.
Things to follow-up:
- CustomQueryRule interface is already declared in
`x-pack/solutions/security/plugins/security_solution/common/api/detection_engine/model/rule_schema/rule_schemas.gen.ts`
as `QueryRuleCreateProps`
- DETECTION_ENGINE_RULES_URL and DETECTION_ENGINE_RULES_BULK_ACTION are
already declared in `@kbn/security-solution-plugin/common/constants`
It would be great if all of that is extracted from the plugin to a
package so it can be reused instead of having to duplicate the code.
Until the package is not ready to be used and has not been introduced to
the different teams, appex-qa and myself will be the owners of it to
make sure that best practices are followed
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
## Summary
Creates a wrapper plugin around the alerts table, that registers a basic
alerts table embeddable panel for dashboards.
> [!NOTE]
> This PR is a preparation work for the [embeddable alerts
table](https://github.com/elastic/kibana/issues/197483). The feature is
disabled for end-users while waiting for other dependent PRs to be
integrated with this, and uses a partially hard-coded table
configuration for testing purposes. The final panel will be fully
configurable by the user.
## Verification steps
1. Uncomment this line
4d49e98b4d/x-pack/platform/plugins/shared/embeddable_alerts_table/public/plugin.ts (L34)
(I'm using a comment to avoid polluting the embeddable examples app with
this panel for a short time)
2. Create one or more ES Query rules that fire alerts
3. Visit the Dashboards page and create a dashboard, then enter edit
mode
4. Click "Add panel"
5. Under "Visualizations" choose "Alerts table"
6. Check that the table panel was created correctly
6.1. Shows any alerts fired by the ES Query rule(s)
6.2. Check that the table adapts correctly to the panel when resizing,
and all normal interactions with the alerts table work correctly
(adding/removing fields, opening alerts in flyouts, using row/bulk
actions)
6.3. Check that panels respond to the global time filter (only time
filters, not KQL search or filters)
6.4. Check that panels respond to individual time filters (⛭ icon >
Apply custom time range)
11. Create a role with access to dashboards but without any alerting
capability and a user assigned to that role
12. Repeat steps 3 and 4, and verify that the "Alerts table" option
isn't available under "Visualizations"
13. Add any alerting capability to the role, such as Management > Stack
rules
14. Repeat steps 3 and 4, and verify that the "Alerts table" is
available again
## References
Closes#203611
### 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/src/platform/packages/shared/kbn-i18n/README.md)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
The intent is to have a centralised place to store the list of Kibana
solutions and serverless project types.
To that end, this PR creates a `@kbn/projects-solutions-groups` package.
It also adds the new solution type `'chat'`.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR reworks how APM handles getting its sources data, elevating the
necessary code to a private shared plugin so that Discover for Traces
can access the data and handle user provided configuration. It also
removes the need for Discover for Traces to rely on the APM static data
view, so the Trace data source and document profile will work on any
compatible/configured index, even in ESQL mode.
Closes#211414
<img alt="ESQL Discover Traces Screenshot 2025-03-04 173032"
src="https://github.com/user-attachments/assets/f5bbb736-8b8b-45dc-ac23-4bf7083aa47e"
/>
## How to test
Test with olbt-cli instance for now, will post for doing with synthtrace
data. Ensure the following is added to your kibana.dev.yml:
```yaml
discover.experimental.enabledProfiles:
- observability-traces-data-source-profile
```
- Make sure your space has the Observability solution view configured
- Go to Discover page
- Select Data Views mode if required and create a view with a `traces`
specific index. Or use the APM static data view.
- The default columns on the page should show the summary column with
four of the following badges: `service.name`, `event.outcome`,
`transaction.name`, `transaction.duration.us`, `span.name`,
`span.duration.us`
- Go to ESQL mode with the query targetting a `traces` index
- The default columns should show the same as in Data View mode
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Irene Blanco <irene.blanco@elastic.co>
## Summary
Closes https://github.com/elastic/streams-program/issues/170 and
https://github.com/elastic/streams-program/issues/171
## Reviewer notes
It's worth reading the research in
https://github.com/elastic/streams-program/issues/168 to understand why
certain decisions were made. Some of the resolving code is inspired by
`grok-js`, unfortunately this wasn't something we could use directly.
The design / UX is **not** final. This is just a functional version. The
editor is currently on the streams > enrichment page so it can be played
with, this will **not** be merged.
There is pattern support for our ECS patterns, I have not added the
legacy ones.
There will almost certainly be some edge cases that don't work, every
repo for a Grok tool I looked at had their own 😅 I've tried to test this
with lots of varied examples though.
I'd recommend unticking "No extension" from the file filter to remove
the pattern files.
<img width="323" alt="Screenshot 2025-03-06 at 22 40 19"
src="https://github.com/user-attachments/assets/5b594f5f-0b0f-4ed0-ae10-2412fcf9e31a"
/>
## Possible improvements / followups
- We could in the future expand the UI to toggle on and off certain
pattern collections.
- Ability to add custom patterns (like in our Grok debugger). This can
still be achieved with `(?<queue_id>[0-9A-F]{10,11})` syntax.
- Point out when regex is invalid (right now it's silent).
- I've copied over the patterns from the ES repo for now, with a light
script to generate an object from them. There's a CLI skeleton in place
if we feel we want to actually pull these from the ES repo directly.
These patterns don't change often, and aren't heavy size wise.
- Debouncing etc for processing, but I'd like to see how the final UX
ends up.
## Media
Screenshot
Simple example
Complex example
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Exposes an Inference (plugin) API client for scripts, that mimicks the
`chatComplete` and `output` APIs that are available on its start
contract. It depends on the KibanaClient that is exposed from the
`@kbn/kibana-api-cli` package. It automatically selects a connector if
available.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Adds a basic api for finding suggested dashboards by alert.
This internal API is currently not in use anywhere.
This api finds suggested dashboards in two ways:
1. Finding dashboards with lens visualizations that query against the
same data view
2. Finding dashboards with lens visualizations that utilize fields in
the rule configuration, or alert data.
These are two naive approaches to finding suggested dashboards. These
heuristics will be improved over time and incorporate more sophisticated
approaches that have been explored by numerous engineers across
Observability.
## Testing
A basic api integration test is included that covers matching dashboards
by index and field, across spaces. As we develop this feature further
over time more fine grain tests will be added
### Manual Testing
1. Run
```
node x-pack/scripts/data_forge.js --events-per-cycle 200 --lookback now-1h --ephemeral-project-ids 10 --dataset fake_stack --install-kibana-assets --kibana-url http://localhost:5601 --event-template bad
```
2. Save the file as a .ndjson file and import it via saved objects
import
https://p.elstc.co/paste/3BWKIHLU#f0WfGYx7G9DhWy88yDXhaEXTX16Fn+ovDcomNIx6E3a
3. Navigate to the alert details page, you should start to see a lot of
alerts
4. Click on one, and copy the alert id
5. Navigate to console and paste `GET
kbn:/internal/observability/alerts/suggested_dashboards?alertId=[YOUR_ALERT_ID]`
to see the recommended dashboards
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Nick Peihl <nickpeihl@gmail.com>
Download, parse and replay loghub data with Synthtrace, for use in the
Streams project. In summary:
- adds a `@kbn/sample-log-parser` package which parses Loghub sample
data, creates valid parsers for extracting and replacing timestamps,
using the LLM
- add a `sample_logs` scenario which uses the parsed data sets to replay
Loghub data continuously as if it were live data
- refactor some parts of Synthtrace (follow-up work captured in
https://github.com/elastic/kibana/issues/212179)
## Synthtrace changes
- Replace custom Logger object with Kibana-standard ToolingLog
- Report progress and estimated time to completion for long-running jobs
- Simplify scenarioOpts (allow comma-separated key-value pairs instead
of just JSON)
- Simplify client initialization
- When using workers, only bootstrap once (in the main thread)
- Allow workers to gracefully shutdown
- Downgrade some logging levels for less noise
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Resolves#212919
We noticed that setting the header `'Content-Type':
'text/event-stream',` didn't work as the browser's native EventSource
implementation.
```JS
return res.ok({
headers: {
'Content-Type': 'text/event-stream',
'Cache-Control': 'no-cache',
},
body: observableIntoEventSourceStream(events$ as unknown as Observable<ServerSentEvent>, {
signal: abortController.signal,
logger,
}),
});
```
The reason, apparently, is that we need to flush the compressor's buffer
negotiated in the HTTP request.
### How to test it:
Run Kibana with examples `yarn start --no-base-path --run-examples
--http2` and open the SSE example app in Kibana. You should see a clock
updating every second in the UI (the clock is coming from the server).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
The esql types are around many packages and plugins creating problems
either with the bundle size or cyclic dependencies.
This PR is moving some of them on the esql-types package. I am going to
move more there in follow up PRs.
(I decided to rename it as it makes more sense to have a generic one for
esql rather one only for the variables)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Marco Vettorello <vettorello.marco@gmail.com>
## Summary
* Remove some old paths pointing to `packages/kbn-pm` (no longer
exists).
* ~Fix group and visibility for `@kbn/streams-app-wrapper-plugin`~.
(done in https://github.com/elastic/kibana/pull/212210)
* Update `scripts/relocate` logic with latest enhancements.
* Convert `@kbn/observability-synthetics-test-data` folder name to
camel-case (messes up with pre-commit hook).
## 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>
This PR moves the `streams` and `streams_app` plugins into platform so
they can be used in other solutions in the future. This PR is not
actually making it available in other solutions yet since we are still
discussing the release plans.
## Inlined helpers
As discussed before, this PR inlines a couple simple helper methods for
query building, time zone normalization, a header portal helper and a
data plugin timefilter state react integration hook as there is no good
place for these outside of the observability solution.
## streams_app plugin
The streams_app plugin is not actually registering anything, instead it
simply exports a component that renders the app which needs to be
consumed by another plugin to turn it into a registered app - for now,
`observability_streams_wrapper` takes over this job.
## observability_streams_wrapper plugin
While 99% of the streams logic is moved into the
`platform/shared/streams_app`, two bits are left behind in
`observability_streams_wrapper`:
* The actual app registration
* Integration with the observability_shared `PageTemplate` component
Once we decide streams should be displayed outside of the observability
solution, it's probably not necessary anymore to decouple app definition
and registration like this because it will always be visible no matter
the solution. Once this is the case, the navigation registration can be
moved into the central `observability` plugin, like it's handled with
other apps like infra.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
These where the only packages under `src/dev/packages`.
The goal long term is to refactor the code under `src/dev` and to
migrate it to one (or multiple) packages.
Thus, we're moving them to `src/core/test-helpers/`, which already
exists and contains a bunch of test-helpers.
#### 2 packages(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/core-test-helpers-kbn-server` |
`src/core/test-helpers/kbn-server` |
| `@kbn/core-test-helpers-model-versions` |
`src/core/test-helpers/model-versions` |
<details >
<summary>Updated references</summary>
```
./.github/codeql/codeql-config.yml
./package.json
./packages/kbn-ts-projects/config-paths.json
./src/core/system/tsconfig.type_check.json
./src/core/test-helpers/kbn-server/jest.config.js
./src/core/test-helpers/model-versions/jest.config.js
./src/dev/tsconfig.type_check.json
./src/platform/packages/private/kbn-repo-packages/package-map.json
./src/plugins/kibana_usage_collection/tsconfig.type_check.json
./src/plugins/usage_collection/tsconfig.type_check.json
./tsconfig.base.json
./tsconfig.base.type_check.json
./tsconfig.refs.json
./x-pack/platform/plugins/shared/fleet/tsconfig.type_check.json
./x-pack/platform/plugins/shared/spaces/tsconfig.type_check.json
./x-pack/plugins/actions/tsconfig.type_check.json
./x-pack/plugins/alerting/tsconfig.type_check.json
./x-pack/plugins/task_manager/tsconfig.type_check.json
./yarn.lock
.github/CODEOWNERS
```
</details><details >
<summary>Updated relative paths</summary>
```
src/core/test-helpers/kbn-server/jest.config.js:12
src/core/test-helpers/kbn-server/tsconfig.json:2
src/core/test-helpers/model-versions/jest.config.js:12
src/core/test-helpers/model-versions/tsconfig.json:2
```
</details>
The storage adapter helper is a very generic package. This PR moves it
out of the observability server utils into a dedicated package to better
reflect this and to be able to use it from non-observability contexts.
The same applies to the observability es client. This PR moves it as
well and renames it to `TracedEsClient` in the same way.
---------
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).
#### 3 packages(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/securitysolution-data-table` |
`x-pack/solutions/security/packages/data-table` |
| `@kbn/ecs-data-quality-dashboard` |
`x-pack/solutions/security/packages/ecs-data-quality-dashboard` |
| `@kbn/security-solution-side-nav` |
`x-pack/solutions/security/packages/side-nav` |
<details >
<summary>Updated references</summary>
```
./.i18nrc.json
./package.json
./packages/kbn-ts-projects/config-paths.json
./src/platform/packages/private/kbn-repo-packages/package-map.json
./tsconfig.base.json
./tsconfig.base.type_check.json
./tsconfig.refs.json
./x-pack/solutions/security/packages/data-table/jest.config.js
./x-pack/solutions/security/packages/ecs-data-quality-dashboard/jest.config.js
./x-pack/solutions/security/packages/side-nav/jest.config.js
./yarn.lock
.github/CODEOWNERS
```
</details><details >
<summary>Updated relative paths</summary>
```
x-pack/solutions/security/packages/data-table/jest.config.js:11
x-pack/solutions/security/packages/data-table/tsconfig.json:2
x-pack/solutions/security/packages/ecs-data-quality-dashboard/jest.config.js:24
x-pack/solutions/security/packages/ecs-data-quality-dashboard/tsconfig.json:10
x-pack/solutions/security/packages/ecs-data-quality-dashboard/tsconfig.json:2
x-pack/solutions/security/packages/side-nav/jest.config.js:10
x-pack/solutions/security/packages/side-nav/tsconfig.json:2
```
</details>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
As part of the SKA, some groups of modules have been broken-down and
relocated in different folders, negatively impacting DX. This is the
case for `serverless` modules, that are spread across:
```
- packages/serverless # storybook config
- src/platform/packages/private/serverless
- src/platform/packages/shared/serverless
```
The goal of this PR is to unify them back under
`src/platform/packages/shared/severless`.
In this scenario, I believe the simplification is worth the trade off.
CC @elastic/kibana-management @elastic/appex-sharedux WDYT?
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
As part of the SKA, some groups of modules have been broken-down and
relocated in different folders, negatively impacting DX. This is the
case for `kbn-management` modules, that are spread across:
```
- packages/kbn-management (storybook config)
- src/platform/packages/private/kbn-management
- src/platform/packages/shared/kbn-management
```
The goal of this PR is to unify them back under
`src/platform/packages/shared/kbn-management`.
In this scenario, I believe the simplification is worth the trade off.
CC @elastic/kibana-management WDYT?
Co-authored-by: Matthew Kime <matt@mattki.me>
## 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).
#### 4 packages(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/alerting-rule-utils` |
`x-pack/platform/packages/shared/alerting-rule-utils` |
| `@kbn/observability-alert-details` |
`x-pack/solutions/observability/packages/alert-details` |
| `@kbn/observability-alerting-test-data` |
`x-pack/solutions/observability/packages/alerting-test-data` |
| `@kbn/observability-get-padded-alert-time-range-util` |
`x-pack/solutions/observability/packages/get-padded-alert-time-range-util`
|
<details >
<summary>Updated references</summary>
```
./.i18nrc.json
./package.json
./packages/kbn-ts-projects/config-paths.json
./src/platform/packages/private/kbn-repo-packages/package-map.json
./tsconfig.base.json
./x-pack/platform/packages/shared/alerting-rule-utils/jest.config.js
./x-pack/solutions/observability/packages/alert-details/jest.config.js
./x-pack/solutions/observability/packages/alerting-test-data/jest.config.js
./x-pack/solutions/observability/packages/get-padded-alert-time-range-util/jest.config.js
./yarn.lock
.github/CODEOWNERS
```
</details><details >
<summary>Updated relative paths</summary>
```
x-pack/platform/packages/shared/alerting-rule-utils/jest.config.js:10
x-pack/platform/packages/shared/alerting-rule-utils/tsconfig.json:2
x-pack/solutions/observability/packages/alert-details/jest.config.js:10
x-pack/solutions/observability/packages/alert-details/tsconfig.json:2
x-pack/solutions/observability/packages/alerting-test-data/jest.config.js:10
x-pack/solutions/observability/packages/alerting-test-data/tsconfig.json:2
x-pack/solutions/observability/packages/get-padded-alert-time-range-util/jest.config.js:10
x-pack/solutions/observability/packages/get-padded-alert-time-range-util/tsconfig.json:2
```
</details>
## 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).
#### 3 packages(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/response-ops-alerts-apis` |
`src/platform/packages/shared/response-ops/alerts-apis` |
| `@kbn/response-ops-alerts-fields-browser` |
`src/platform/packages/shared/response-ops/alerts-fields-browser` |
| `@kbn/response-ops-alerts-table` |
`src/platform/packages/shared/response-ops/alerts-table` |
<details >
<summary>Updated references</summary>
```
./package.json
./packages/kbn-ts-projects/config-paths.json
./src/platform/packages/private/kbn-repo-packages/package-map.json
./src/platform/packages/shared/response-ops/alerts-apis/jest.config.js
./src/platform/packages/shared/response-ops/alerts-fields-browser/jest.config.js
./src/platform/packages/shared/response-ops/alerts-table/jest.config.js
./tsconfig.base.json
./yarn.lock
.github/CODEOWNERS
```
</details><details >
<summary>Updated relative paths</summary>
```
src/platform/packages/shared/response-ops/alerts-apis/jest.config.js:12
src/platform/packages/shared/response-ops/alerts-apis/tsconfig.json:2
src/platform/packages/shared/response-ops/alerts-fields-browser/jest.config.js:12
src/platform/packages/shared/response-ops/alerts-fields-browser/tsconfig.json:2
src/platform/packages/shared/response-ops/alerts-table/jest.config.js:12
src/platform/packages/shared/response-ops/alerts-table/tsconfig.json:2
```
</details>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Umberto Pepato <umbopepato@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).
#### 1 packages(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/logs-overview` | `x-pack/platform/packages/shared/logs-overview`
|
<details >
<summary>Updated references</summary>
```
./package.json
./packages/kbn-ts-projects/config-paths.json
./src/platform/packages/private/kbn-repo-packages/package-map.json
./tsconfig.base.json
./x-pack/.i18nrc.json
./x-pack/platform/packages/shared/logs-overview/jest.config.js
./yarn.lock
.github/CODEOWNERS
```
</details><details >
<summary>Updated relative paths</summary>
```
x-pack/platform/packages/shared/logs-overview/jest.config.js:10
x-pack/platform/packages/shared/logs-overview/tsconfig.json:2
```
</details>
## 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).
#### 1 packages(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/search-shared-ui` | `x-pack/solutions/search/packages/shared-ui`
|
<details >
<summary>Updated references</summary>
```
./package.json
./packages/kbn-relocate/utils/transforms.ts
./packages/kbn-ts-projects/config-paths.json
./src/platform/packages/private/kbn-repo-packages/package-map.json
./tsconfig.base.json
./x-pack/.i18nrc.json
./x-pack/solutions/search/packages/shared-ui/jest.config.js
./yarn.lock
.github/CODEOWNERS
```
</details><details >
<summary>Updated relative paths</summary>
```
x-pack/solutions/search/packages/shared-ui/jest.config.js:14
x-pack/solutions/search/packages/shared-ui/tsconfig.json:2
```
</details>
## 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 packages(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/observability-ai-common` |
`x-pack/solutions/observability/packages/observability-ai/observability-ai-common`
|
| `@kbn/observability-ai-server` |
`x-pack/solutions/observability/packages/observability-ai/observability-ai-server`
|
<details >
<summary>Updated references</summary>
```
./package.json
./packages/kbn-ts-projects/config-paths.json
./src/platform/packages/private/kbn-repo-packages/package-map.json
./tsconfig.base.json
./x-pack/solutions/observability/packages/observability-ai/observability-ai-common/jest.config.js
./x-pack/solutions/observability/packages/observability-ai/observability-ai-server/jest.config.js
./yarn.lock
.github/CODEOWNERS
```
</details><details >
<summary>Updated relative paths</summary>
```
x-pack/solutions/observability/packages/observability-ai/observability-ai-common/jest.config.js:10
x-pack/solutions/observability/packages/observability-ai/observability-ai-common/tsconfig.json:2
x-pack/solutions/observability/packages/observability-ai/observability-ai-server/jest.config.js:10
x-pack/solutions/observability/packages/observability-ai/observability-ai-server/tsconfig.json:2
```
</details>
## 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).
#### 3 packages(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/observability-utils-browser` |
`x-pack/solutions/observability/packages/utils-browser` |
| `@kbn/observability-utils-common` |
`x-pack/solutions/observability/packages/utils-common` |
| `@kbn/observability-utils-server` |
`x-pack/solutions/observability/packages/utils-server` |
<details >
<summary>Updated references</summary>
```
./package.json
./packages/kbn-ts-projects/config-paths.json
./src/platform/packages/private/kbn-repo-packages/package-map.json
./tsconfig.base.json
./x-pack/solutions/observability/packages/utils-browser/jest.config.js
./x-pack/solutions/observability/packages/utils-common/jest.config.js
./x-pack/solutions/observability/packages/utils-server/jest.config.js
./x-pack/solutions/observability/packages/utils-server/jest.integration.config.js
./yarn.lock
.github/CODEOWNERS
```
</details><details >
<summary>Updated relative paths</summary>
```
x-pack/solutions/observability/packages/utils-browser/jest.config.js:10
x-pack/solutions/observability/packages/utils-browser/tsconfig.json:2
x-pack/solutions/observability/packages/utils-common/jest.config.js:10
x-pack/solutions/observability/packages/utils-common/tsconfig.json:2
x-pack/solutions/observability/packages/utils-server/jest.config.js:10
x-pack/solutions/observability/packages/utils-server/jest.integration.config.js:10
x-pack/solutions/observability/packages/utils-server/tsconfig.json:2
```
</details>
### Summary
- Closes#89741
This PR contains the resulting work of a massive effort that ports our
on top bundler abstraction (called @kbn/optimizer) from Webpack v4 into
Webpack v5. It's essential in terms of long term maintenance since v4
was not receiving updates any longer but will also unblock some new
features that could be beneficial for our future DevEx endeavours.
Next you can find a small list of all the accomplished tasks on this
journey.
### Completed Tasks
- [x] Upgrade dependencies to match the ones on webpack v5
- [x] Fix null-loader usages
- [x] Fix raw-loader usages
- [x] Fix file-loader usages
- [x] Fix url-loader usages
- [x] Fix `@kbn/optimizer-webpack-helpers` to support webpack v5
- [x] Adopt previous webpack v4 polyfill-all strategy with
node-polyfill-webpack-plugin
- [x] Fix theme-loader on @kbn/optimizer
- [x] Migrate configurations and ad-hoc loader options on all webpack
configs from v4 to v5
- [x] Fix @kbn/test jest resolver for file-loader cases
- [x] Migrate public-path loader on UiSharedDeps
- [x] Fix all usages of webpack-merge
- [x] Migrate BundleRemoteModule
- [x] Migrate BundleRemotesPlugin
- [x] Correctly migrate PopulateBundleCachePlugin
- [x] Correctly migrate BundleMetricsPlugin
- [x] Check if the profiling plugins still work (--profile flag)
- [x] Recover if possible the previous webpack v4 cacheGroup chunks
rename to something like `data.plugin.chunk.0.js`
- [x] Run `/ci` and make sure we get our first green CI, otherwise work
on the errors until we do
- [x] Profile and solve bottlenecks until we get a cold build
performance similar to the one we had on webpack v4 (`node
scripts/build_kibana_platform_plugins --no-cache`).
- [x] OpenSSL Legacy Warnings: try to remove `--openssl-legacy-provider
` flags
- [x] Add Webpack to Renovate config
- [x] Explore removing `NodePolyfillPlugin`
([here](https://www.npmjs.com/package/node-polyfill-webpack-plugin)) and
add each polyfill needed individually per each webpack config to check
if we get smaller bundles. If we do it's better to go with the case by
case need approach instead of deploying a bunch of polyfills with
NodePolyfillPlugin. As another alternative, create a custom smaller
plugin with only the union of all needed polyfills.
- [x] Evaluate if we want to touch the resolutions on mainFields and
conditionNames
- [x] Understand why `@import 'src/core/public/mixins'` does not work
anymore (not a problem, we should use relative paths anyway but we want
to track why it changed from v4 to v5)
- [x] BUG: Child compilers are having errors hidden and/or changed from
error to warning
- [x] Fix license check for
[Artistic-2.0](https://spdx.org/licenses/Artistic-2.0.html) is the
license for
[domain-browser](https://github.com/bevry/domain-browser?tab=License-1-ov-file).
This package is a dependency of
[NodePolyfillPlugin](https://www.npmjs.com/package/node-polyfill-webpack-plugin).
Artistic 2.0 license is [classified as
yellow](https://github.com/elastic/open-source/blob/main/elastic-product-policy.md#yellow-list)
and should only be used for dev dependencies.
- [x] Make sure `resourceQuery: { not: /raw/ }` is not necessary on
other webpack configs like storybook one
- [x] Find what is being wrongly removed by usedExports optimization;
hint: I believe it is identifying a lot of exports inside the sync entry
of plugins as unused exports and removing them. Then `__kbnBootstrap__`
can't be found
- [x] Rebalance @kbn/optimizer pickMaxWorkerCount
- [x] Re-open the issue to fix sass-warnings
[#190345](https://github.com/elastic/kibana/issues/190345) or downgrade
sass-loader to v10
- [x] Remove previous esm no parse rules
- [x] Confirm esm support is working
- [x] Confirm console override is needed
- [x] Confirm react prod builds on ui shared deps for distributable
- [x] Remove customization for
[xyflow](https://github.com/xyflow/xyflow) from webpack configs
- [x] Clean all the code
- [x] Make sure collected metrics from stats are still aligned with what
we were collecting before; also verify if the modules used for optimizer
caches etc are well generated (@kbn/node-libs-browser)
- [x] Fix watch performance
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Brad White <brad.white@elastic.co>
## Summary
This PR turns the AlertsTable into a standalone component, making it
independent from the `TriggersActionsUI` plugin.
#### Removes the alerts table registry
All configuration is now managed through the AlertsTable component
props. Shared configurations are handled by giving consumers the ability
to directly provide alerts table wrapper components (see for example the
`renderAlertsTable` prop of `getCases`).
#### Moves the alerts table to dedicated package(s)
Following the feature-driven structure we're introducing for ResponseOps
(alerting) client-side packages:
- `@kbn/response-ops-alerts-table`
- `@kbn/response-ops-alerts-apis`
- `@kbn/response-ops-alerts-fields-browser`
#### Initial work on improving composition and organization
- Reorganizes the table code into a by-entity-type folder structure
(`components/`, `hooks/`, ...)
- Simplifies some components and breaks into smaller units when possible
## To verify
For consumers of the alerts table:
- Check that all your tables have the same behavior as before (columns,
sort, row actions, bulk actions, etc.)
- Check that your "shared" tables (i.e. cases alerts view in O11y and
Security) have the expected configuration and behavior
> [!WARNING]
> This PR moves a lot of files. Git might not always recognize the
correct delete/add file pairs. If you see weird diffs feel free to reach
out for help!
### 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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
### Identify risks
| Risk | Description | Severity | Mitigation |
|---|---|---|---|
| Table misconfigurations | Some table configurations might slightly
differ from the previous AlertsTableRegistry-backed version | Low |
Quick fix |
## References
Closes#195180
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Christos Nasikas <xristosnasikas@gmail.com>
## Summary
`@kbn/scout-oblt` is a test library that extends `@kbn/scout` with test
helpers specifically designed to test `Observability` applications in
Kibana. All Oblt plugins should only import from `@kbn/scout-oblt`
Its primary goal is to simplify the test development experience for
teams working on `Observability` plugins by providing custom Playwright
fixtures, page objects, and utilities tailored for Observability-related
testing scenarios.
Contributing:
- when Fixture/Page Object is sharable across all Solutions and Platform
(`fleetApi` fixture), it should be added in `@kbn/scout`
- when Fixture/Page Object is Oblt-specific but is shared across tests
under the multiple plugins (`OnboardingHome` page), it should be added
in `@kbn/scout-oblt`
- when Fixture/Page Object is only used in a single plugin (`onboarding`
internal APIs ?), it should be added in this plugin.
I also re-worked existing tests with few ideas in mind:
- Scout is **e2e testing tool** and should target primary e2e test
scenarios; We have _API integration tests_ to test multiple short
scenarios for APIs behavior (response, status code) and _jest/React
testing library_ to test components in isolation (elements rendering,
fields validation). Doing all the testing with e2e tool like Playwright
will dramatically affect cost efficiency and stability of tests, but
also slows overall CI execution and PRs delivery. The goal is to follow
testing pyramid and keep in mind its principles.
- We on purpose spin up new browser context for each `test` block to
make sure our **tests are independent**. Having too many short `test`
blocks in the file significantly slows down the execution: every block
triggers browser context, saml authentication, adding/removing Fleet
integrations (each call up to 2 seconds) and other beforeEach/afterEach
hooks. Real browser-based testing is expensive. It is not about putting
every step into 1 `test` block, but also not a Jest unit-test-style
design. When it is possible to group similar actions on the same page
and if it is a part of the same user flow - we should do it. It also
doesn't bring the testing value repeating the same UI steps multiple
times in different scenarios. _Our CI costs are critical to cut when it
is possible_
- Avoid **nesting describe** blocks: it complicates test readability and
also complicates for CI bot to properly skip the failing block (it will
skip the top level one). We encourage **Scout parallel test execution**
based on running test spec files in multiple workers, not the `test`
blocks within the same file. Having too many `test` blocks in the same
file will be slowly run in the single thread and in case of flakiness,
it means Team lose more test coverage than they probably expect.
Before (**59** test blocks - **8-8.5 min** per distro):
<img width="1709" alt="Screenshot 2025-02-08 at 18 01 40"
src="https://github.com/user-attachments/assets/5fd65a1c-85f9-4594-9dae-3f8e99a005ab"
/>
After (**15** test blocks - **3.5-4 min** per distro):
<img width="1578" alt="Screenshot 2025-02-10 at 18 14 42"
src="https://github.com/user-attachments/assets/6846898f-7dd2-4f6b-8bc5-d06741b0b120"
/>
For reviewers: updated tests are possible to run in 2 parallel workers
against the same Kibana/ES instance and run time is dropping to **2.5-3
min** 🚀 . It is up to UX-Logs team to decide if you want to keep
parallel run (new tests can be added either to parallel or sequential
run)
<img width="1578" alt="Screenshot 2025-02-11 at 12 14 30"
src="https://github.com/user-attachments/assets/e94113f2-d7f1-470e-a6d5-cb5154d99c41"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Resolves#209261
## Summary
Removes the code used to render Logs Explorer. This does not result in
any functional changes.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
* Categorise and move `@kbn/timelines-plugin` as _platform/shared_,
target location: `x-pack/platform/plugins/shared/timelines`.
This helps reduce the scope of the illegal dependencies from `osquery`
plugin towards _security/private_ code.
cc @tomsonpl
* Simplify path and rename `@kbn/observability-alerting-rule-utils`
(platform/shared):
```
# Before
@kbn/observability-alerting-rule-utils
x-pack/platform/packages/shared/observability/alerting_rule_utils/
# After
@kbn/alerting-rule-utils
x-pack/platform/packages/shared/alerting_rule_utils/
```
* Simplify path and rename `@kbn/observability-logs-overview`
(platform/shared):
```
# Before
@kbn/observability-logs-overview
x-pack/platform/packages/shared/observability/logs_overview/
# After
@kbn/logs-overview
x-pack/platform/packages/shared/logs_overview/
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
