## Summary
Fix broken tests !!
These got broken due to changes on alerts overview page, i am also
expanding the scope to run on all observability plugin changes !!
Add streams API to documentation as an experimental feature
<img width="2555" alt="Screenshot 2025-03-07 at 11 44 54"
src="https://github.com/user-attachments/assets/f54e5e6e-0c20-4bad-9cff-27747d0f76e2"
/>
There are a couple of changes in here:
* Split streams API in internal and public and mark the public parts as
experimental
* Add the public parts to the Kibana documentation
* Add description and summary
* Adjust the server repository wrapper to pass through summary and
description
# To test
* Generate OAS bundle: `node scripts/capture_oas_snapshot --include-path
/api/streams --update`
* Apply overlays `cd oas_docs && make api-docs`
* Make sure bump.sh is installed (`npm install -g bump-cli`)
* Run for preview: `cd oas_docs && bump preview output/kibana.yaml`
# Open questions
* Does the split into public and internal make sense?
* Is it a problem if this is visible in the user-facing documentation
page before we actually release streams? Or would it be OK if the API is
marked as experimental? (mostly a question for @LucaWintergerst )
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Trying to fix pipeline failure due to not enough disk space:
```
| 2025-03-12 10:47:33 UTC | Copying cached snapshots from /opt/buildkite-agent/.es-snapshot-cache/cache to .es/cache
| 2025-03-12 10:47:48 UTC | cp: error writing '.es/cache/elasticsearch-9.0.0-SNAPSHOT-linux-x86_64.tar.gz': No space left on device
| 2025-03-12 10:47:48 UTC | cp: error writing '.es/cache/elasticsearch-9.0.0-SNAPSHOT-linux-x86_64.tar.gz.meta': No space left on device
| 2025-03-12 10:47:48 UTC | cp: error writing '.es/cache/elasticsearch-9.1.0-SNAPSHOT-linux-x86_64.tar.gz': No space left on device
| 2025-03-12 10:47:48 UTC | cp: error writing '.es/cache/elasticsearch-9.1.0-SNAPSHOT-linux-x86_64.tar.gz.meta': No space left on device
```
## Summary
Closes - https://github.com/elastic/kibana/issues/166679
## What's included ?
- The PR adds a feature in Logs View of Observability (to start with) to
hide the regular pagination toolbar from the footer and show Load More
only when the user has scrolled to the bottom of the page.
- The table would always load the items in batches of default set 500
- This PR also add 2 helper functions `useThrottleFn` and
`useDebounceFn`. Current React help library which KIbana uses called
-`react-use` does not have these and we cannot use Lodash variant of
these. We need such hooks which are React safe. Hence added these 2
## What's pending ?
- [x] Unit tests for the 2 new helper React hooks
- [x] Unit tests for data table footer component
- [x] Unit tests for Profile Resolution
- [x] Functional Serverless Tests
- [x] Functional Stateful Tests
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Davis McPhee <davismcphee@hotmail.com>
Co-authored-by: Felix Stürmer <weltenwort@users.noreply.github.com>
Co-authored-by: Davis McPhee <davis.mcphee@elastic.co>
## Summary
related to https://github.com/elastic/kibana/pull/211797
Fixing bootstrap failure in
https://buildkite.com/elastic/kibana-on-merge-unsupported-ftrs/builds/34167
```
yarn install and bootstrap, attempt 2
2025-03-11 18:13:27 UTC yarn run v1.22.22
2025-03-11 18:13:27 UTC $ node scripts/kbn bootstrap --force-install
2025-03-11 18:13:27 UTC Kibana should not be run as root. Use --allow-root to continue.
2025-03-11 18:13:27 UTC error Command failed with exit code 1.
2025-03-11 18:13:27 UTC info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
2025-03-11 18:13:28 UTC 🚨 Error: The command exited with status 1
```
**Addresses:** https://github.com/elastic/kibana/issues/180267
## Summary
This PR enables `prebuiltRulesCustomizationEnabled` feature flag.
## Details
Besides simply enabling `prebuiltRulesCustomizationEnabled` feature flag the following required changes were done
- failed tests due enabling the FF were fixed
- FF setting was removed from test configurations (integrations and Cypress tests)
- FF logic was removed from the codebase. Disabling the FF would require roll back test changes as well. So just in case we have to disable the FF it's simpler to roll back the PR's commit.
## Summary
closes https://github.com/elastic/kibana/issues/211592
This PR improves the way we run scout tests by discovering all the
plugins that have the scout tests and run tests in multiple workers:
<img width="1586" alt="image"
src="https://github.com/user-attachments/assets/4936ab50-fefb-470c-af3a-21263b58143f"
/>
How it works:
1. Run search script to find _all existing_ scout playwright config
files across kibana repo
2. Save results into `.scout/scout_playwright_configs.json` file, that
will be used as source to run configs in individual jobs per plugin.
Upload it as BK artifact.
3. Spin up job for each plugin mentioned in
`scout_playwright_configs.json`
4. In each individual job use `scout_playwright_configs.json` and get
configs for specific plugin, use worker with 8 vcpus where tests are run
in parallel (`usesParallelWorkers` prop)
While running configs 1 by 1 collect command exit code with the
following rules:
- configs run passed => exit code `0` , final status remains `0`
- config has no tests => exit code `2`, put config name into
`configsWithoutTests` group to push BK annotation later, change exit
status to `0` - we accept configs without tests at current stage
- config run fails => exit code `1`, final status changed to `1` and job
will fail in the end; put config name into `failedConfigs` group to push
BK annotation later
<img width="1564" alt="Screenshot 2025-02-21 at 14 34 16"
src="https://github.com/user-attachments/assets/06e9298d-466c-46bb-8e85-3d691a40850a"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
When VM image rebuild is triggered after ES promotion, only the cache
warmup should be built.
This PR also separates the daily full build to a daily base + cache
build (in case ES promotions are failing for some reason, we should
still have a daily cache refresh).
Requires: https://github.com/elastic/ci-agent-images/pull/1295
With this, we'd run a daily base image build and cache build (~40m +
25m) + cache warmups for every promotion (~4x 25m) instead of a full
build and promotion per build (~4x 55m). Ultimately not that much of a
gain 🤷 (4*55=220m => 40+5x25=165m)
## Summary
- addresses https://github.com/elastic/kibana/issues/179767
- ignore_fields tests run as expected on basic/essentials license, so
moved to that tier
- moves the rest of files in `general_logic` set of tests to basic
level, apart from synthetic source tests that requires platinum(trial)
license
## 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>
**Addresses:** https://github.com/elastic/kibana/issues/202078
**Partially implements test plan:** https://github.com/elastic/kibana/pull/205922
## Summary
This PR implements the Rule Upgrade test plan added in https://github.com/elastic/kibana/pull/205922 and https://github.com/elastic/kibana/pull/203331.
## Details
Tests cover only enabled customization and organized in a following way
- `diffable_rule_fields` folder contains per field tests. It focuses on `DiffableRule`* fields. Each field has rule preview and upgrade scenarios throughly covered. Assertion on stats are included in rule preview tests to make sure the maximum coverage with reasonable execution time. **Diffable rule fields` tests were moved to a separate execution group to avoid exceeding execution limits.**
- `preview_prebuilt_rules_upgrade.ts` integration tests on `/internal/prebuilt_rules/upgrade/_review` endpoint. It uses only `name` and `tags` fields to minimize tests complexity. Basically it should be considered as smoke tests.
- `upgrade_prebuilt_rules` integrations test on `/internal/prebuilt_rules/upgrade/_perform` endpoint. It uses only `name` and `tags` fields to minimize tests complexity. Basically it should be considered as smoke tests.
This PR supersedes https://github.com/elastic/kibana/pull/205217 and https://github.com/elastic/kibana/pull/205339.
* `DiffableRule` was added in the scope of prebuilt rules customization epic to serve rule upgrades preview and performing upgrades. It represents slightly reorganized rule fields to simplify prebuilt rule upgrade workflow handling. There are utility functions transforming between `RuleResponse` and `DiffableRule`.
## Flaky test runner
Flaky test runs for 100 iterations were successful (https://github.com/elastic/kibana/pull/209260#issuecomment-2649027038 and https://github.com/elastic/kibana/pull/209260#issuecomment-2649627389).
Closes https://github.com/elastic/kibana/issues/205146
## Summary
We run a session clean up task that opens a point in time query to try
and delete any older sessions in the session index. We've noticed that
this task fails quite often with the same error
`no_shard_available_action_exception`. On investigating, it's possible
that the point in time query is opened when there are no shards
available for that index. This PR fixes that by checking if the PIT
query fails with 503 bails if it throws the error - allowing the task to
be tried again in the next run of the task manager. We allow for up to
10 failures of the clean up task in succession before logging an error.
### Testing
Unfortunately, there's no reliable way to simulate missing shards
locally. I've added a new integration test config here:
```
node scripts/functional_tests_server.js --config x-pack/test/security_api_integration/session_shard_missing.config.ts
```
This overrides the ES function to return 503 when opening PIT query and
then attempts to assert the result from the task manager.
### Release note
Updates session cleanup mechanism to account for potential missing
shards in Session index.
### 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
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
[kibana-flaky-test-suite-runner#7836](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7836)
- [ ] 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)
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
### 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
In #210425 we added Scout UI tests to be run for on-merge pipeline, but
test results are not ingested by default.
This PR enables Scout reporter for that pipeline
## 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>
## Summary
Updated dependencies for Threat Hunting Explore tests. This means
Explore tests will now run when there are changes to the dashboard
shared component.
The change maintains all existing dependencies while adding this new one
plus some of the Investigations Team, ensuring that:
1. No other teams' test suites are affected
2. Explore tests keep running on their previous dependencies
3. Explore tests will additionally run when dashboard container files
change
## 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>
Pre-GA, we previously modified the critical path, weekly Quality Gate
pipelines over to non-preemptible images in order to avoid the
inconsistent "agent lost" Buildkite issue that might cause unnecessary
churn.
Now that we're GA, the periodic pipelines are becoming more critical
path as well, and in addition, we're seeing a concerning increase in the
number of "agent lost" issues we're encountering, as described here:
https://github.com/elastic/security-team/issues/11700
As such, this PR is hoping to address this issue for the periodic
pipelines as well.
## Summary
Add MapsPage to the scout core to be re-used by others.
Add rudimentary docs to show how to run these tests.
Added a `waitForRender` method.
Add test id.
---------
Co-authored-by: Robert Oskamp <traeluki@gmail.com>
Co-authored-by: Nick Partridge <nicholas.partridge@elastic.co>
Co-authored-by: Nick Partridge <nick.ryan.partridge@gmail.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
**Resolves:** https://github.com/elastic/security-team/issues/10410
## Summary
We want to make Rule Customization available at higher license tiers.
### **Intended Workflows/UX**
#### **Basic/Platinum/Security Essentials License Tiers**
- **Editing Prebuilt Rules:**
- Allow the 8.16 behavior: only actions, exceptions, snoozing, and
enable/disable options can be modified.
- On the rule editing page, all tabs except *Actions* are disabled.
Disabled tabs will display a hover explanation:
- "Upgrade to Enterprise to enable prebuilt rule customization" for ECH.
- "Upgrade to Security Complete to enable prebuilt rule customization"
for Serverless.
<img width="356" alt="image"
src="https://github.com/user-attachments/assets/72e60933-aaaf-45a0-9660-4cd066d3afec"
/>
- Rule editing via API is not restricted (tracked separately:
https://github.com/elastic/security-team/issues/11504.
- **Bulk Actions:**
- Modifications to rule content via bulk actions are not allowed.
Prebuilt rules are excluded from bulk actions if the license level is
insufficient. Users will see an explanation for the exclusion.
- Serverless
<img width="737" alt="image"
src="https://github.com/user-attachments/assets/99fef72f-dd38-4c73-a9e3-7b4c8018b4ed"
/>
- ECH
- On the API level (`_bulk_action`), an error is returned if a user
tries to modify a prebuilt rule without the required license. Response
in this case looks like this:
```json
{
"statusCode": 500,
"error": "Internal Server Error",
"message": "Bulk edit failed",
"attributes": {
"errors": [
{
"message": "Elastic rule can't be edited",
"status_code": 500,
"rules": []
}
]
}
}
```
- **Rule Updates:**
- Updates are restricted to Elastic’s incoming updates only.
- The rule upgrade flyout is in read-only mode.
<img width="949" alt="image"
src="https://github.com/user-attachments/assets/16a56430-63e6-4096-8ffd-b97f828abdd4"
/>
- For previously customized rules where customization is now disabled
due to insufficient licensing, a notification will appear on the upgrade
flyout, clarifying that only an upgrade to Elastic's version is
available.
- On the API level (`_perform`), only requests with `pick_version =
target` are permitted. Requests with `rule.fields` values are not
allowed.
API response when `pick_version` is not `target`:
```json
{
"message": "Only the 'TARGET' version can be selected for a rule update;
received: 'CURRENT'",
"status_code": 400
}
```
API response when the `fields` value is provided:
```json
{
"message": "Rule field customization is not allowed. Received fields:
name, description",
"status_code": 400
}
```
- **Customized Rules:**
- Existing customizations remain intact, and the “Modified” badge is
retained
- On the rule management, monitoring, and update tables:
- On the rule update flyout:
- On the rule details page:
- When we edit a rule with customizations (e.g., change rule's actions),
the rule should stay marked as customized
- **Import/Export Scenarios:**
- These are handled separately
(https://github.com/elastic/security-team/issues/11502)
#### **Enterprise/Security Complete License Tiers**
- All rules can be fully edited
- Upgraded prebuilt or customized rules will have an editable view,
enabling full customization
## Summary
This PR adds quick-checks regarding pipeline resource definitions.
- Adds validation/correction for `locations.yml`
- Adds validation for definitions (through
`docker.elastic.co/ci-agent-images/pipelib rre validate`).
- Also fixes a missing pipeline entry in `locations.yml`
Example for when a YML error bounces on schema validation:
https://buildkite.com/elastic/kibana-pull-request/builds/270652#0194a8d5-48df-4f1b-8ec7-1f076851d138
Example for auto-fixing missing location:
b2170ac53a
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
- Centralized Scout reporter settings
- Added owner area and config/test file information to reporter events
- Attempt to upload events at the end of a test run
- Enable Scout reporter test events upload for the `pull request` and
`on merge` pipelines
## Summary
https://buildkite.com/elastic/kibana-on-merge/builds/60136 shows how
even though some preliminary checks failed, some cypress tests started
after the build step was successful. It's probably because they had
explicit dependencies, but only on a subset of the pre-checks.
## Summary
As K8S Dashboard is currently hidden on main , the code serves no
purpose other than potentially causing Tech debts whenever a refactor or
a migration happens. As such its better to remove it completely. In case
we want to bring it back later we will just pull it from git history
> [!CAUTION]
> **This should only affect Serverless and Main, 8.x.x should still be
able to see and access K8S Dashboard**
## Related Tickets
- https://github.com/elastic/security-team/issues/11418
- https://github.com/elastic/security-team/issues/10735
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Paulo Silva <paulo.henrique@elastic.co>
Co-authored-by: Maxim Kholod <maxim.kholod@elastic.co>
## Summary
Closes https://github.com/elastic/kibana/issues/203967
Supports dashboard variables in ES|QL charts.
This PR introduces the first phase of ES|QL controls. In this phase:
- the flow starts from Lens ES|QL editor (and no vice-versa, this will
happen on a later phase after we discuss some technical details with ES)
- it is only available for dashboards (we want to include them in other
apps as Discover but this is the next phase driven by the presentation
team)
- it supports variables for intervals, fields and values. I haven't
added support for functions. I am going to do it after this PR being
merged (there are some business questions I want to answer first)
For more info check this
[deck](https://docs.google.com/presentation/d/1qSbWLSoC5SseXuLix763vpp8sa7ikp3pQTbHImEHBoc)
### Implementation details
- There is a new service, the ESQLVariables service that is responsible
for ES|QL variables. I isolated this to a new plugin owned by the ES|QL
team for cleaner code and for avoiding circular dependencies
- A new ESQL_CONTROL type got created. It follows the exact same logic
as the rest controls. No changes in the architecture here.
- The creation of the controls (the control forms) have been added in
the esql plugin.
- Lens has small changes:
- The support of variables in the textBased datasource
- Two callbacks needed to be called after the creation / cancellation of
an ES|QL control
### Types of ES|QL variables
We have 2 types:
- Static Values (the user gives a list of values with his own
responsibility). As the flow starts from the editor we can identify what
they most possibly want to do and we give the user some options but they
have the freedom to do as they want. A basic validation has been added
too.
- Values from an ES|QL query (the user gives an ES|QL query that
generates the values). As the flow starts from the editor we can suggest
a query for the users but they can always change it as they wish.
<img width="1168" alt="image"
src="https://github.com/user-attachments/assets/cc28beb8-111c-43ad-9f26-865bc62ae512"
/>
### Example of a control creation from the editor
### Release note
ES|QL charts now allow the creation of controls in dashboards. You can
control a part of the query such as a field, an interval or a value.
### Checklist
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [x] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [x] [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)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Andrea Del Rio <delrio.andre@gmail.com>
Co-authored-by: Devon Thomson <devon.thomson@elastic.co>
## Summary
This PR adds `spaceTest` interface to `kbn-scout` to run space aware
tests, that can be executed in parallel. Most of Discover tests were
converted to parallel run because we see runtime improvement with 2
parallel workers.
Experiment 1: **ES data pre-ingested**, running 9 Discover **stateful**
tests in **5 files** locally
| Run setup | Took time |
| ------------- | ------------- |
| 1 worker | `1.3` min |
| 2 workers | `58.7` sec |
| 3 workers | `48.3` sec |
| 4 workers | **tests fail** |
Conclusion: using **2** workers is the optimal solution to continue
Experiment 2: Running Discover tests for stateful/serverless in **Kibana
CI** (starting servers, ingesting ES data, running tests)
| Run setup | 1 worker | 2 workers | diff
| ------------- | ------------- |------------- |------------- |
| stateful, 9 tests / 5 files | `1.7` min | `1.2` min | `-29.4%`|
| svl ES, 8 tests / 4 files | `1.7` min | `1.3` min | `-23.5%`|
| svl Oblt, 8 tests / 4 files | `1.8` min | `1.4` min | `-22.2%`|
| svl Search, 5 tests / 2 files | `59.9` sec | `51.6` sec | `-13.8%`|
Conclusion: parallel run effectiveness benefits from tests being split
in **more test files**.
Experiment 3: Clone existing tests to have **3 times more test files**
and re-run tests for stateful/serverless in **Kibana CI** (starting
servers, ingesting ES data, running tests)
| Run setup | 1 worker | 2 workers | diff
| ------------- | ------------- |------------- |------------- |
| stateful, 27 tests / 15 files | `4.3` min | `2.7` min | `-37.2%`|
| svl ES, 24 tests / 12 files | `4.3` min | `2.7` min | `-37.2%`|
Conclusion: parallel run effectiveness is **increasing** with more test
files in place, **not linear** but with good test design we can expect
**up to 40%** or maybe a bit more.
How parallel run works:
- `scoutSpace` fixture is loaded on Playwright worker setup (using
`auto: true` config), creates a new Kibana Space, expose its id to other
fixtures and deletes the space on teardown.
- `browserAuth` fixture for parallel run caches Cookie per worker/space
like `role:spaceId`. It is needed because Playwright doesn't spin up new
browser for worker, but only new context.
- kbnClient was updated to allow passing `createNewCopies: true` in
query, it is needed to load the same Saved Objects in parallel
workers/spaces and generate new ids to work with them. `scoutSpace`
caches ids and allows to reach saved object by its name. This logic is
different from single thread run, where we can use default ids from
kbnArchives.
How to run parallel tests locally, e.g. for stateful:
```
node scripts/scout run-tests --stateful --config x-pack/platform/plugins/private/discover_enhanced/ui_tests/parallel.playwright.config.ts
```
