Closes: #214335
**Description**
Dialog modal, flyout, field visible title should be announced for the
users, especially using assistive technology to know what dialog modal,
flyout opened, what field is active and what is needed to enter in it.
**Changes made:**
1. Added `aria-labelledby={flyoutTitleId}` for mentioned places
## Summary
It seems there's been some sort of unintended bundle limit branch
through 2 minor changes (greenlit separately on PRs) - and this one
broke the camel's back: https://github.com/elastic/kibana/pull/212163
## Summary
Fixes the #207204
This PR introduces a new complementary function for an Expression
definition named `sideEffects`, this goes together with the other `fn`
function and it is used to restore any side effect when the caching
system kicks in.
I haven't found how to programmatically test this.
Will add an FTR if it can be reliable to reproduce an expression caching
scenario.
### 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 notes
The request inspector now shows the correct request and response in any
successful scenario.
## Summary
This PR introduces the first building blocks for the [Entity Analytics
Privileged
Monitoring](https://github.com/elastic/security-team/issues/9971).
We follow the approach used in the Entity Store and add a new "Engine",
which consists of the following components:
* Public API
* INIT and HEALTH routes
* Kibana task
* Privilege Monitoring Data Client
* Engine Saved Object
* API key manager
* Related storage indices
* Feature Flag: `privilegeMonitoringEnabled` set to `false` by default.
* API integration test configuration
* only tests that the health endpoint is available
* Auditing and Telemetry
## Testing steps
1. Make sure to add `privilegeMonitoringEnabled` to your
`kibana.dev.yaml`
2. In devtools, ensure the API is working with `GET
kbn:/api/entity_analytics/monitoring/privileges/health`
3. Start the engine with: `POST
kbn:/api/entity_analytics/monitoring/engine/init`
4. Look for `DEBUG` logs mentioning the
`entity_analytics:monitoring:privileges:engine` task
---------
Co-authored-by: CAWilson94 <charlotte.wilson@elastic.co>
Co-authored-by: Charlotte Alexandra Wilson <CAWilson94@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/206556
This PR adds a setting to remote ES outputs for also uninstalling
integrations on remote clusters when integrations sync is enabled.
This new setting can be toggled in the UI with a new switch:
<img width="1728" alt="Screenshot 2025-04-09 at 11 53 43"
src="https://github.com/user-attachments/assets/34544aa9-28fd-4360-a32f-5031e3d4293f"
/>
### Testing
* Follow the steps in
https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/fleet/dev_docs/local_setup/remote_clusters_ccr.md
to set up two clusters with integrations syncing.
* Add some integrations in your main cluster and check that they are
also installed in the remote cluster.
* Disable uninstalling integrations on remote.
* Remove an integration in your main cluster and check that it is NOT
removed from the remote cluster.
* Enable uninstalling integrations on remote.
* Remove an integration in your main cluster and check that it is also
removed from the remote cluster.
* In your remote cluster, enroll an agent onto a policy that points to
at least 1 package policy of the installed integrations (cf. Docker
commands below if using dockerized fleet-server/agent).
* In your main cluster, uninstall the integration that is used by the
agent policy in the remote. This should cause the uninstall to fail into
the remote cluster.
* In your remote cluster, inspect the package SO of that integration
with `GET .kibana_ingest/_search?q=type:epm-packages`: the
`latest_uninstall_failed_attempts` field should be populated.
Docker command for running a fleet-server in your remote cluster:
```
docker run \
-e ELASTICSEARCH_HOST=http://host.docker.internal:9500 \
-e KIBANA_HOST=http://host.docker.internal:5701/<path> \
-e KIBANA_USERNAME=elastic \
-e KIBANA_PASSWORD=changeme \
-e KIBANA_FLEET_SETUP=1 \
-e FLEET_INSECURE=1 \
-e FLEET_SERVER_ENABLE=1 \
-e FLEET_SERVER_POLICY_ID=fleet-server-policy \
-p 8220:8220 \
--rm docker.elastic.co/beats/elastic-agent:9.0.0-SNAPSHOT
```
Docker command for enrolling an agent in your remote cluster:
```
docker run \
-e ELASTICSEARCH_HOST=http://host.docker.internal:9500 \
-e KIBANA_HOST=http://host.docker.internal:5701/<path> \
-e FLEET_URL=https://host.docker.internal:8220 \
-e FLEET_ENROLL=1 \
-e FLEET_ENROLLMENT_TOKEN=<token> \
-e FLEET_INSECURE=1 \
--rm docker.elastic.co/beats/elastic-agent:9.0.0-SNAPSHOT
```
### Checklist
- [ ] 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
- [ ] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Identify risks
This feature is currently in development and behind the
`enableSyncIntegrationsOnRemote` feature flag.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR adds the structure for workchat FTR tests and adds a few initial
tests as an example.
### Details about initially added tests
New test directories:
- `x-pack/test_serverless/api_integration/test_suites/chat`
- load a few common tests (that run on all project types)
- run `platform` security tests (taken over from `search` project type)
- `x-pack/test_serverless/functional/services/svl_chat_navigation.ts`
- load the `home page` common test
- run a simple navigation test, using the `svlChatNavigation` service
that has been introduced as an example
Note that these tests mostly serve as examples to prove things are
actually running and will have to be adjusted / removed / extended over
time. The purpose of this PR is NOT to add proper test coverage.
Closes#213469
---------
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.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
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>
## Summary
This PR makes `security` a required field for route registration. To
incorporate the new required filed, changes has been made:
1. **Test file updates**. A lot of the updates made in this PR were made
in tests.
2. **Versioned route security configuration**. For the versioned route
`security` config has been lifted up to the top-level definition:
Before
```ts
router.versioned
.get({
path: '/api/path',
options: { ... },
...
}, handler)
.addVersion({
version: 1,
validate: false,
security: {
authz: {
requiredPrivileges: ['privilege'],
},
},
});
```
After
```ts
router.versioned
.get({
path: '/api/path',
options: { ... },
security: {
authz: {
requiredPrivileges: ['privilege'],
},
},
...
}, handler)
.addVersion({
version: 1,
validate: false,
});
```
3. **Type adjustments for route wrappers**. Type changes has been made
in:
-
`x-pack/solutions/observability/plugins/infra/server/lib/adapters/framework/adapter_types.ts`
-
`x-pack/solutions/observability/plugins/metrics_data_access/server/lib/adapters/framework/adapter_types.ts`
-
`x-pack/solutions/observability/plugins/synthetics/server/routes/types.ts`
-
`x-pack/solutions/observability/plugins/uptime/server/legacy_uptime/routes/types.ts`
Security was made an optional field for the wrappers defined in those
files, since the default security is provided in the wrapper itself and
then passed down to the core router.
### 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] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
__Closes: https://github.com/elastic/kibana/issues/215331__
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
PR reduces unifiedSearch chunks into ui chunk, action chunk, and a
autocomplete chunk.
### Before
<img width="350" alt="Screenshot 2025-03-14 at 8 47 10 AM"
src="https://github.com/user-attachments/assets/f54fe21e-7548-48a1-8874-e36377826701"
/>
### After
The second chunk request is because search bar loads KQL suggestions.
This will be addressed in a follow up PR and the search bar will lazy
load suggestions only when interacted with.
<img width="350" alt="Screenshot 2025-03-14 at 12 56 28 PM"
src="https://github.com/user-attachments/assets/8f23ee56-a57a-489b-aeab-caa30f739d03"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@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
With this PR we make `RuleActionsField` component and relevant
validations reusable outside of and not bound to the rules management.
As part of the Attack Discovery Scheduling
[feature](https://github.com/elastic/security-team/issues/10142) we
would like to be able to setup schedules (similar to detection rules,
just named differently within the feature space) and be able to add
actions (email, slack, webhook etc.).
Currently `RuleActionsField` lives inside the
`x-pack/solutions/security/plugins/security_solution/public/detection_engine/rule_creation/components/`
folder. We could just reference it from within the Attack Discovery
folder, but for better code structure it will be good to put it into a
common place.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
-
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/8075
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR is - at its core - only moving a handful of files around. A lot
of of these files lived under the `detections` folder, but were almost
exclusively used in files under the `detection_engine` folder. This is
why the PR seems so huge. Almost everything modified here is only files
imports...
Here are the few files that were actually moved around:
1. The files `detection_engine.tsx`, `detection_engine_no_index.tsx`,
`detection_engine_user_unauthenticated.tsx` (and their respective test
files) have been moved from
`security_solution/public/detections/pages/detection_engine` to
`security_solution/public/detections/pages/alerts`. I thought about
renaming them as well, but felt like there was already enough changes.
Renaming will be done in a follow up PR.
2. The content of the
`security_solution/public/detections/pages/detection_engine/rules`
folder was moved to `security_solution/public/detection_engine/common`
as almost the entire folder content is only used within the
`security_solution/public/detection_engine` folder.
#### Notes
_If there is a better folder for the files moved to the
`detection_engine/common` folder, feel free to suggest. I'll be happy to
make the change!_
The CODEOWNERS file has been updated and simplified accordingly.
Only imports should have been modified. No code, logic or UI changes!
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
After https://github.com/elastic/kibana/pull/214843, `axios` client
usages need to set a flag to prevent the vulnerable behavior.
To reviewers: if you think it's a mistake, and you created a client to
request for absolute URLs, consider unsetting the `baseURL` to
communicate intent.
## 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
Stop emitting any `.js` files during typechecking. We only depend on the
declarations, not the emitted, compiled javascript files.
An added benefit, is making some bad import errors more obvious.
We'll no longer try to build javascript files in place if a poor
import/require is made, rather the error of importing outside projects
(in the forest of a bunch of errors possibly) will be visible in the
typescript logs:
```
# instead of:
proc [tsc] error TS5055: Cannot write file '/opt/buildkite-agent/builds/bk-agent-prod-gcp-1741789017236110254/elastic/kibana-pull-request/kibana/src/platform/packages/shared/kbn-babel-register/cache/no_cache_cache.js' because it would overwrite input file.
# we'll see:
... several others like this
proc [tsc] src/platform/packages/shared/kbn-grok-ui/scripts/generate_patterns.js:10:9 - error TS6307: File '/Users/alex/Git/elastic-kibana/src/setup_node_env/index.js' is not listed within the file list of project '/Users/alex/Git/elastic-kibana/src/platform/packages/shared/kbn-grok-ui/tsconfig.type_check.json'. Projects must list all files or use an 'include' pattern.
proc [tsc]
proc [tsc] 10 require('../../../../../setup_node_env');
... several others like this
```
## Summary
After upgrading the ES client to 9.0
(https://github.com/elastic/kibana/pull/208776), we noticed that the CI
fails to upload the results of the tests to the CI cluster:
```
ERROR ResponseError: media_type_header_exception
Caused by:
status_exception: Accept version must be either version 8 or 7, but found 9. Accept=application/vnd.elasticsearch+json; compatible-with=9
Root causes:
media_type_header_exception: Invalid media-type value on headers [Content-Type, Accept]
```
This PR makes sure that the CI client is still using v8.x until we
upgrade that cluster.
## Summary
This PR updates `DEFAULT_THEME_TAGS` used to determine what theme tags
are bundled in Kibana by default to only include the Borealis theme,
specifically `borealislight` and `borealisdark` theme tags. This change
is expected to decrease bundle sizes significantly and get back to
bundling a single theme, not two (4 → 2 theme tags).
Now that Serverless, `9.0`, and `main` all run with Borealis, there's no
risk in removing Amsterdam from the bundle and decreasing Kibana bundle
sizes.
We need to keep the feature flag in code for the time being to easily
test future Borealis iterations.
Amsterdam will still be available as an opt-in theme and is meant to be
used locally when testing changes to be backported to 8.x versions that
use Amsterdam. To do so, Kibana needs to be started/built with
`KBN_OPTIMIZER_THEMES` environment variable set and the feature flag
overridden in `kibana.dev.yml`.
```yml
# config/kibana.dev.yml
feature_flags.overrides.coreRendering.defaultThemeName: amsterdam
```
```shell
# Run dev server with both borealis and Amsterdam theme tags
KBN_OPTIMIZER_THEMES="borealislight,borealisdark,v8light,v8dark" yarn start
```
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Remove extraneous dependencies:
* `canvas` was depending on 'webpack' purely for a type (dev-time).
* `@kbn/optimizer-webpack-helpers` (canvas depends on it 🤨) was
depending on 'webpack' solely for a function that could be defined in
`@kbn/optimizer` (devOnly).
## Summary
Closes https://github.com/elastic/ingest-dev/issues/4722
### Implementation checklist
- [x] Handle fetching agent policies and agents at scale
- [x] Only consider active agents for upgrade
- [x] Agents already on or upgrading to target version are included in
the count but not considered for upgrade
- [x] Agents stuck in updating are considered for upgrade
- [x] Bulk upgrade actions triggered by the task have an added
`isAutomatic:true` flag
- [x] Use rollout duration to spread bulk upgrade in time (1h or longer
depending on agent count)
### Testing
- This should be tested with real Elastic Agents (that will upgrade and
have `upgrade_details`).
- Edit the task interval in order to test how the task logic handles
agents already upgrading.
- Edit the agents batch size in order to test how the task logic handles
agents at scale.
- We should also check that space awareness is respected if enabled.
### 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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Identify risks
Risk of incorrectly triggering agent upgrades. Probability should be
very low if the agent policy does not have `required_versions` set.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Updating the ES client to 9.0.
Resolves#116102
## What changes?
**Breaking change**: `body` has been removed.
Most of the changes are about bringing all the content inside the body
as a root attribute to the API params:
```diff
const response = await client.search({
index: 'test',
- body: {
query: {
match_all: {}
}
- }
})
```
For this reason, enabling the "Hide whitespace changes" option when
reviewing is recommended.
Some exceptions to this rule:
* Bulk APIs replace the `body` array with `operations` array (direct
replacement)
* Index Put Settings API replace `body` array with `settings` (direct
replacement)
* Msearch replaces the `body` array with `searches` array (direct
replacement)
* Document Index API replaces `body` with `document` (direct
replacement)
* Create Repository replaces `body` with `repository` (direct
replacement)
Because of a known issue in the client
(https://github.com/elastic/elasticsearch-js/issues/2584), there's still
an escape hatch to send data in the body in case the specific use case
requires it via `// @ts-expect-error elasticsearch@9.0.0
https://github.com/elastic/elasticsearch-js/issues/2584`, but it
shouldn't be abused because we lose types. In this PR we've used it in
those scenarios where we reuse the response of a GET as the body of a
PUT/POST.
### Other changes
* `estypes` can be imported from the root of the library as `import type
{ estypes } from '@elastic/elasticsearch';`
* `estypesWithBody` have been removed
* `requestTimeout`'s 30s default has been removed in the client. This PR
explicitly adds the setting in all client usages.
### Identify risks
- [x] The client places unknown properties as querystring, risking body
params leaking there, and causing 400 errors from ES => Solved by
forcing `body` usage there via `// @ts-expect-error elasticsearch@9.0.0
https://github.com/elastic/elasticsearch-js/issues/2584`. The next
version of the client will address this.
- [x] We need to run the MKI tests to make sure that we're not breaking
anything there =>
https://elastic.slack.com/archives/C04HT4P1YS3/p1739528112482629?thread_ts=1739480136.231439&cid=C04HT4P1YS3
---------
Co-authored-by: Gloria Hornero <gloria.hornero@elastic.co>
## 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>
## Summary
This PR improves how **Synthtrace** resolves the Kibana URL when only
`--target` (Elasticsearch) is provided or when neither `--target` nor
`--kibana` is specified. The CLI now attempts to **automatically
discover** the appropriate URLs based on the provided arguments.
Some adjustments were made to improve this discovery process, especially
when running **locally in Serverless mode**, where Kibana may be using
`http`, while Elasticsearch (ES) is on `https`. Additionally,
self-signed certificates do not work with the IP address `127.0.0.1`, so
this PR defaults to `localhost` and warns the user if `127.0.0.1` is
detected in Serverless mode.
### **Improvements**
- If either of `--target` or `--kibana` or neither provided, the CLI
attempts to **discovers the URLs** dynamically now in both Stateful and
Serverless.
- Defaults to `localhost` instead of `127.0.0.1` to avoid SSL
certificate issues.
- Provides a **clear error message and hint** when Kibana and ES use
different protocols (http vs https) and either or both are unreachable.
### **Expected Behavior After This PR**
These commands should now work **seamlessly** in both **local Stateful**
and **Serverless** modes:
```sh
✗ node scripts/synthtrace simple_logs
```
For **Serverless mode**, these also work:
```sh
✗ node scripts/synthtrace simple_logs --kibana=http://elastic_serverless:changeme@localhost:5601
```
```sh
✗ node scripts/synthtrace simple_logs --target=https://elastic_serverless:changeme@localhost:9200 --kibana=http://elastic_serverless:changeme@localhost:5601
```
### **(Side Note) Serverless Kibana with SSL Disabled**
However, the following command will **fail** with an error message if
Kibana is running without SSL, while Elasticsearch is using `https`:
```sh
✗ node scripts/synthtrace simple_logs --target=https://elastic_serverless:changeme@localhost:9200
```
#### **Error Output:**
```sh
Loading scenario from kibana/packages/kbn-apm-synthtrace/src/scenarios/simple_logs.ts
Error: Could not connect to Kibana. request to https://elastic_serverless:changeme@localhost:5601/ failed, reason: write EPROTO 400882F501000000:error:0A00010B:SSL routines:ssl3_get_record:wrong version number:../deps/openssl/openssl/ssl/record/ssl3_record.c:355:
If your Kibana URL differs, consider using the '--kibana' parameter to customize it.
```
**Solution:**
If you must have to provide `--target` (non defaults), also provide
`--kibana` or start Kibana with SSL enabled.
```sh
✗ yarn start --serverless=oblt --ssl
```
## Summary
In #211918 I added config validation check to skip run if there are no
tests in playwright config.
It turned out that Playwright init reporters even when `--list` command
is passed and no tests are executed, that lead to Scout reports being
loaded and then causing reporter error when the other command runs the
tests:
```
proc [playwright] info Calling save with destination: /Users/dmle/github/kibana/.scout/reports/scout-playwright-9518363d47816953
proc [playwright] ERROR Error: Save destination path '/Users/dmle/github/kibana/.scout/reports/scout-playwright-9518363d47816953' already exists
proc [playwright] at ScoutEventsReport.save (/Users/dmle/github/kibana/packages/kbn-scout-reporting/src/reporting/report/events/report.ts:56:13)
proc [playwright] at ScoutPlaywrightReporter.onEnd (/Users/dmle/github/kibana/packages/kbn-scout-reporting/src/reporting/playwright/events/playwright_reporter.ts:277:19)
proc [playwright] at ReporterV2Wrapper.onEnd (/Users/dmle/github/kibana/node_modules/playwright/lib/reporters/reporterV2.js:91:165)
proc [playwright] at /Users/dmle/github/kibana/node_modules/playwright/lib/reporters/multiplexer.js:71:117
proc [playwright] at wrapAsync (/Users/dmle/github/kibana/node_modules/playwright/lib/reporters/multiplexer.js:112:18)
proc [playwright] at Multiplexer.onEnd (/Users/dmle/github/kibana/node_modules/playwright/lib/reporters/multiplexer.js:69:31)
proc [playwright] at InternalReporter.onEnd (/Users/dmle/github/kibana/node_modules/playwright/lib/reporters/internalReporter.js:77:12)
proc [playwright] at finishTaskRun (/Users/dmle/github/kibana/node_modules/playwright/lib/runner/tasks.js:90:26)
proc [playwright] at runTasks (/Users/dmle/github/kibana/node_modules/playwright/lib/runner/tasks.js:73:10)
proc [playwright] at Runner.runAllTests (/Users/dmle/github/kibana/node_modules/playwright/lib/runner/runner.js:72:20)
proc [playwright] at runTests (/Users/dmle/github/kibana/node_modules/playwright/lib/program.js:211:18)
proc [playwright] at t.<anonymous> (/Users/dmle/github/kibana/node_modules/playwright/lib/program.js:54:7)
```
The simplest solution is to explicitly disable Scout reporter for config
validation command.
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
There is no need to start servers (~1.5 min run time) if there are no
tests matching filters or maybe config itself has all tests skipped.
This PR uses Playwright cli with `--list` flag to quickly validate
playwright config and exit with status code `2` (`1` is reserved for
errors during servers start or test failures). it also useful to know in
advance how many tests were about to run:
case 1: tests found
```
$ node scripts/scout.js run-tests --config x-pack/platform/plugins/private/discover_enhanced/ui_tests/parallel.playwright.config.ts --serverless=security
info scout: Test server configuration saved at /Users/dmle/github/kibana/.scout/servers/local.json
info scout: Validate Playwright config has tests
info scout: Total: 5 tests in 2 files
info Verifying Docker is installed.
│ info Docker version 20.10.14, build a224086349
...
```
case 2: no tests found
```
$ node scripts/scout.js run-tests --config x-pack/solutions/observability/plugins/observability_onboarding/ui_tests/playwright.config.ts --stateful
info scout: Test server configuration saved at /Users/dmle/github/kibana/.scout/servers/local.json
info scout: Validate Playwright config has tests
ERROR scout: No tests found in [x-pack/solutions/observability/plugins/observability_onboarding/ui_tests/playwright.config.ts]
```
## Summary
There's a high likelihood that this causes some unwanted behavior where
the promise is not resolved and the `node` process just exists without
any error.
## 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>
