[One Workflows] [CI:Validation] New package to validate workflows examples#269078
Closed
dej611 wants to merge 197 commits into
Closed
[One Workflows] [CI:Validation] New package to validate workflows examples#269078dej611 wants to merge 197 commits into
dej611 wants to merge 197 commits into
Conversation
dej611
added
release_note:skip
|
🤖 Jobs for this PR can be triggered through checkboxes. 🚧
ℹ️ To trigger the CI, please tick the checkbox below 👇
|
Contributor
💔 Build Failed
Failed CI Steps
Test Failures
Metrics [docs]Module Count
Async chunks
History
|
…out on home page (elastic#271207) ## Summary Closes elastic/security-team#17408 When a user lacks \`read\` access to the leads index (\`.entity_analytics.entity-leads-*\`), the Top Threat Hunting Leads section was silently hidden with no user-facing explanation. This PR folds missing leads-index read privileges into the existing unified \`EntityAnalyticsReadPrivilegesCallout\` at the top of the Entity Analytics home page. - Extracts a shared \`useLeadGenerationPrivileges\` hook from the inline \`useQuery\` in \`useHuntingLeads\` — the same React Query \`queryKey\` ensures both call sites share a single network request via deduplication - Extends \`EntityAnalyticsReadPrivilegesCallout\` with an optional \`leadGenerationPrivileges\` prop, merging missing-read entries into the existing unified callout (no duplicate banners) - Wires \`useLeadGenerationPrivileges\` in \`EntityAnalyticsHomePage\`, gated on \`leadGenerationEnabled\`, and passes data to the callout - Section-hiding behavior is unchanged: Top Threat Hunting Leads stays hidden when \`leadsReadPermissionError=true\` ## Test plan - [ ] With the \`leadGenerationEnabled\` feature flag enabled, as a user missing \`read\` on \`.entity_analytics.entity-leads-*\`: the unified "Insufficient privileges" callout lists the leads index; the Top Threat Hunting Leads section is hidden - [ ] As a user with full privileges: no callout from the leads index; the section renders normally - [ ] As a user missing both risk-engine and leads read privileges: a single combined callout (not two separate banners) ## Manual testing steps **Prerequisites** - Kibana running locally with \`leadGenerationEnabled: true\` in \`kibana.dev.yml\` (or xpack.securitySolution.enableExperimental: ['leadGenerationEnabled']) - Entity Store initialized (Security -> Entity Analytics -> Manage Entity Store -> Start) - An Enterprise license (dev license or trial) **Scenario 1 — Full privileges (baseline)** 1. Log in as a user with full privileges (e.g. built-in \`elastic\` superuser) 2. Navigate to **Security → Entity Analytics** 3. ✅ Expected: No "Insufficient privileges" callout; **Top Threat Hunting Leads** section is visible at the top of the page **Scenario 2 — Missing leads \`read\` privilege** 1. Create a role that grants access to Security but is missing \`read\` on the \`.entity_analytics.entity-leads-*\` index pattern 2. Log in as a user with that role 3. Navigate to **Security → Entity Analytics** 4. ✅ Expected: - "Insufficient privileges" callout appears at the top of the page - Callout body lists: _Missing \`read\` privileges for the \`.entity_analytics.entity-leads-*\` index_ - **Top Threat Hunting Leads** section is **not** rendered **Scenario 3 — Missing both risk-engine and leads \`read\` privileges** 1. Use a role that is also missing \`read\` on \`risk-score.risk-score-*\` 2. Navigate to **Security → Entity Analytics** 3. ✅ Expected: - A **single** "Insufficient privileges" callout (not two separate banners) - Callout body lists both missing indices: \`risk-score.risk-score-*\` **and** \`.entity_analytics.entity-leads-*\` - **Top Threat Hunting Leads** section is **not** rendered Screenshots taken against a locally-running Kibana with the `leadGenerationEnabled` feature flag enabled: **Scenario 1 — Full privileges** (`01_full_privileges.png`) Top Threat Hunting Leads section visible, no callout rendered. **Scenario 2 — Missing leads `read` privilege** (`02_missing_leads_read_privileges.png`) "Insufficient privileges" callout shown at top of page listing `.entity_analytics.entity-leads-*` index. Top Threat Hunting Leads section hidden. **Scenario 3 — Missing both risk-engine and leads `read` privileges** (`03_missing_both_privileges.png`) Single combined callout listing both `risk-score.risk-score-*` and `.entity_analytics.entity-leads-*`. Top Threat Hunting Leads section hidden. No duplicate banners. Full privileges : <img width="1440" height="900" alt="01_full_privileges" src="https://github.com/user-attachments/assets/d71e53c6-ded4-40f5-9456-c3ad02e0d85d" /> Missing leads read privileges : <img width="1440" height="900" alt="02_missing_leads_read_privileges" src="https://github.com/user-attachments/assets/e5885a9b-ce7f-48c8-927f-29551644f039" /> Missing both privileges : <img width="1440" height="900" alt="03_missing_both_privileges" src="https://github.com/user-attachments/assets/ce694049-30b1-45c6-8b80-659091468180" />
…color_row.tsx (elastic#271378) Adds missing `aria-label` to both `EuiColorPicker` components in the color format editor to resolve `@elastic/eui/no-unnamed-interactive-element` violations. - Added i18n `aria-label` to the text color picker: `"Text color for item {index}"` - Added i18n `aria-label` to the background color picker: `"Background color for item {index}"` ```tsx <EuiColorPicker color={text} aria-label={i18n.translate('indexPatternFieldEditor.color.textColorAriaLabel', { defaultMessage: 'Text color for item {index}', values: { index }, })} ... /> ``` ### Checklist - [x] Read and applied `.agents/skills/accessibility/SKILL.md` - [x] Added label `a11y:agent-pr` - [x] Fixed all files listed in the issue --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Alexey Antonov <alexwizp@gmail.com>
This PR adds a new agentic skill that helps developers and AI agents debug flaky test failures. It first provides context on the different types of pipelines we have, and covers best practices and common investigation pitfalls. This skill is meant to be used by our Flaky Test Fixer agentic workflow (we'll soon have our failed test investigator use the skill.). Local use is just for testing purposes. ### Local testing Invoke the skill manually by prefixing your help request with the `/flaky-test-investigator` command: ``` /flaky-test-investigator can you help me debug this flaky test? elastic#271165 ```
…lity area (elastic#271408) This PR adds the `elastic/observability-bi` to the `observability` code owner <> area mapping. Adding the team here ensures their tests are correctly attributed to the observability area by our Scout Reporter. Co-authored-by: Cursor <cursoragent@cursor.com>
…he query validator factory (elastic#267455) ## Summary Fixes orphaned esql_async Elasticsearch requests left by `esqlQueryValidatorFactory` when the user navigates away from the ES|QL rule edit page. The form field validator debounces a METADATA _id-injected query to fetch columns for _id field validation. Because the validator runs imperatively (outside React's lifecycle), two bugs allowed the request to outlive the component: The `debounceAsync` timer could fire after unmount, starting a brand-new request An in-flight request was never aborted when the component unmounted or when a new validation superseded it ## Changes: `esql_query_edit.tsx` — adds `abortControllerRef` and `isUnmountedRef`, wires a `useEffect` cleanup to abort on unmount, and passes both refs to the validator factory. `esql_query_validator_factory.ts` — guards against post-unmount execution via `isUnmountedRef`, aborts the previous in-flight request before each new validation, and passes the abort signal downstream. `esql_query_columns.ts` — accepts an optional `AbortSignal` and calls `queryClient.cancelQueries` when it fires, propagating cancellation through TanStack Query to the underlying HTTP request. ## How to test Follow the reproduction steps in elastic#266683.
…#271412) ## Summary Plugin names like `cloud_integrations/cloud_links` (introduced by PR elastic#270031) contain slashes that Buildkite rejects as invalid step keys. The `configs` distribution strategy — used by the `kibana-elasticsearch-snapshot-verify` pipeline — passed `module.name` directly as the Buildkite step key, causing the Scout Test Run Builder to fail. The fix sanitizes the step key while preserving the original module name as `SCOUT_CONFIG_GROUP_KEY` so child steps can still resolve their entry in the manifest. ## Changes - Compute a sanitized `stepKey` from `module.name` by replacing any character outside `[a-zA-Z0-9_-:]` with a dash - Pass the original `module.name` as `configGroupKey` and use it for `SCOUT_CONFIG_GROUP_KEY` in the child step env
…r in flyout !! (elastic#270936) ## Summary Fixes a race in the overview flyout's saved-object fetch that 404s for cross-space monitors even when the user has full access (caught by @miguel-martinr on the 8.19 backport of elastic#265748, see [this comment](elastic#270567 (comment))). - `useKibanaSpace` is async, so `space` is `undefined` on the first render. `getMonitorSpaceToAppend(undefined, spaces)` short-circuits to `{}`, the initial `getMonitorAction.get` dispatch goes without `spaceId`, the request hits the active space, and 404s for a cross-space monitor. - The retry that fires once `space` resolves is silently dropped by the `takeLeading` saga in `monitor_details/effects.ts` because the first request is still in flight. - The 404 lands in `syntheticsMonitorError`, `monitorObject` stays `null`, and the flyout body that depends on the SO (`DetailedFlyoutHeader`, `MonitorDetailsPanel`) renders empty. Fix: guard the dispatch on `space` being loaded. `useKibanaSpace` falls back to `{ id: 'default' }` when the spaces plugin is absent, so the guard always resolves. A jest case asserts no `getMonitorAction` is dispatched while `useFetcher` reports `space` as still loading. ## Test plan > Setup: two spaces (e.g. `default`, `team-a`). Create a monitor in `team-a` only, then view the Monitors overview from `default` with "Show from all spaces" enabled (or be a `team-a` member viewing the cross-space row). - [ ] Open the overview flyout for the cross-space monitor from the Monitors page. The flyout body (`DetailedFlyoutHeader` + `MonitorDetailsPanel`) renders fully — no empty space, no 404 callout. - [ ] Network panel: only one `GET /s/team-a/api/synthetics/monitors/<id>` request, no preceding `GET /api/synthetics/monitors/<id>` that 404s. - [ ] Regression: same flow in the default space for a same-space monitor still works. - [ ] Regression: remote monitor flyout still skips the SO fetch (existing `isRemote` early return is preserved). Made with [Cursor](https://cursor.com) Co-authored-by: Cursor <cursoragent@cursor.com>
… !! (elastic#270622) ## Summary When the requested HMR port (`KBN_HMR_PORT` or default `5678`) is held by another process — most commonly a leftover `@kbn/rspack-optimizer` worker from a previous dev session or a sibling Kibana checkout — the optimizer was failing the entire build with a bare `listen EADDRINUSE` and logging a misleading `Waiting for changes to fix errors...`. Kibana would still come up, but no bundles were ever emitted, so the browser saw a 404 on `/<basePath>/<buildShaShort>/bundles/kibana.bundle.js`. This PR makes `HmrServer.start()`: - Retry on an OS-assigned ephemeral port when the requested port is in use. - Log a single warning explaining what happened, including a `lsof -i :PORT` hint. - Let the build proceed normally. Since the bundled HMR client reads the resolved port from the compile config (`run_build.ts` passes `hmrPort` from `hmrServer.start()` into `createSingleCompileConfig`), switching ports is safe at the network layer. It also relaxes the env-var parsing so `KBN_HMR_PORT=0` is now a valid explicit opt-in to ephemeral mode (used by the unit test to avoid depending on `5678` being free on the host where tests run). ## Reproduction (before the fix) ```bash # Simulate the zombie worker node -e "require('http').createServer().listen(5678,'127.0.0.1')" & KBN_USE_RSPACK=true yarn start ``` Result before this PR: ``` [error][@kbn/rspack-optimizer] Build failed: listen EADDRINUSE: address already in use 127.0.0.1:5678 [info ][@kbn/rspack-optimizer] Waiting for changes to fix errors... ``` …followed by `Kibana is now available` but `GET /<basePath>/XXXXXXXXXXXX/bundles/kibana.bundle.js -> 404`. With this PR: ``` [warning][@kbn/rspack-optimizer] HMR port 5678 is already in use (likely a leftover @kbn/rspack-optimizer worker — check \`lsof -i :5678\`). Falling back to an ephemeral port. [success][@kbn/rspack-optimizer] RSPack build completed — 1 entry, 309.16 MB ``` ## Test plan - [x] Existing `HmrServer` jest tests still pass (`node scripts/jest packages/kbn-rspack-optimizer/src/hmr/hmr_server.test.ts`). - [x] New cases: fallback port is allocated, warning is emitted with the right message, SSE traffic works on the fallback port. - [x] Type-check on `packages/kbn-rspack-optimizer/tsconfig.json`. - [x] ESLint on changed files clean. - [ ] Manual repro on local dev with port 5678 squatted — optimizer falls back, `kibana.bundle.js` served, UI loads. Made with [Cursor](https://cursor.com) Co-authored-by: Cursor <cursoragent@cursor.com>
…anager UI (elastic#271377) Two `EuiInMemoryTable` instances in the drilldown manager UI were missing the required `tableCaption` prop, violating `@elastic/eui/require-table-caption`. ### Changes - **`drilldown_template_table`** — Added `tableCaption` with i18n string: *"Drilldown templates"* - **`drilldown_table`** — Added `tableCaption` with i18n string: *"Drilldowns"* ```tsx <EuiInMemoryTable tableCaption={txtTableCaption} items={drilldowns} // ... /> ``` Captions describe the dataset per EUI accessibility guidelines and use `i18n.translate` for localization. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: Alexey Antonov <alexwizp@gmail.com>
## Summary
Today the entity_analytics test trees (`test_suites/entity_analytics`,
`cypress/e2e/entity_analytics`, `cypress/tasks/entity_analytics`) are
co-owned by `@elastic/contextual-security-apps` +
`@elastic/security-entity-analytics`. The two teams actually own
different feature areas inside those trees, so the broad co-ownership
causes:
- review pings and skipped-test attribution to the wrong team;
- `team-auto-tests-stats` inventory reports double-counting skipped TCs
;
- a silently-overridden `entity_store/ → @elastic/core-analysis` line
(the broad co-ownership was winning on last-match).
This PR replaces the broad co-ownership with per-feature lines so each
test subtree maps to its actual owning team:
| Path | Owner |
|---|---|
| `test_suites/entity_analytics/entity_store/` |
`@elastic/core-analysis` |
| `test_suites/entity_analytics/entity_resolution/` |
`@elastic/contextual-security-apps` |
|
`test_suites/entity_analytics/{entity_details,monitoring,watchlists,risk_engine,risk_score_maintainer,utils}/`
| `@elastic/security-entity-analytics` (broad default) |
| `cypress/e2e/entity_analytics/entity_flyout*`,
`entity_analytics_home/entity_analytics_home_page.cy.ts`,
`entities_table.cy.ts`, `entities_table_grouping.cy.ts` | co-owned:
contextual-security-apps + security-entity-analytics |
|
`cypress/e2e/entity_analytics/{asset_criticality_upload_page,dashboards,host_details,hosts,priv_mon,watchlists}`
| `@elastic/security-entity-analytics` (broad default) |
| `cypress/tasks/entity_analytics/entity_flyout_resolution.ts` |
`@elastic/contextual-security-apps` |
| `cypress/tasks/entity_analytics/privmon.ts` |
`@elastic/security-entity-analytics` (broad default) |
| `cypress/tasks/entity_analytics/entity_analytics_home.ts` | co-owned |
### Heads-up for owners
- `@elastic/core-analysis` — the Entity Store API integration tests
under `test_suites/entity_analytics/entity_store/` (the largest
skipped-test cluster, ~37 skipped TCs) now route to your team for
reviews and CI failure attribution. The earlier `@elastic/core-analysis`
assignment for this directory was being silently overridden, so
operationally this is closer to formalizing what the file always
claimed.
- `@elastic/security-entity-analytics` — no new attribution; your
Monitoring, Watchlists, Risk Engine, Risk Score Maintainer, Entity
Details, and Cypress (priv_mon, hosts, dashboards, watchlists,
asset_criticality) tests no longer share ownership with
contextual-security-apps, so review-request distribution gets a bit
cleaner.
### 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)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [ ] [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
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [ ] 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.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] 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)
- [ ] Review the [backport
guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing)
and apply applicable \`backport:*\` labels.
### Identify risks
- **Low** — CODEOWNERS-only change. No code or test behavior is
modified.
- **Operational impact for core-analysis**: PR review requests on the
entity_store API integration tests now route to them rather than the
previous co-owned set. The current line in CODEOWNERS already nominally
assigned this path to them, but was silently overridden — so for some
team members this may look new. Recommend a quick Slack heads-up.
…lastic#270027) Plugins should not async load chunks during plugin setup or start because: * Hides true page load impact from page load bundle size - cheats limits.yml metrics * Causes more work for browser to async load code in separate HTTP requests. In the before image, notice how 2 reporting chunks are loaded on initial home page load <img height="400" alt="Screenshot 2026-05-19 at 1 31 08 PM" src="https://github.com/user-attachments/assets/d68d0419-1618-4a45-b06a-d4f1d56bccff" /> In the after image, notice how 0 reporting chunks are loaded on initial home page load <img height="400" alt="Screenshot 2026-05-19 at 1 30 49 PM" src="https://github.com/user-attachments/assets/935ac43f-7cd1-4ce3-ae73-a399efa03130" /> --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
…ortunities (elastic#271647) - Closes elastic#270615 ## Summary ### Area 1: Field-data behavior — MERGED **Files changed:** - Deleted `src/platform/test/functional/apps/discover/group2_data_grid2/_data_grid_field_data.ts` - Removed its `loadTestFile` entry from `group2_data_grid2/index.ts` - Moved 2 unique grid-specific tests (`doc view should show exact header fields`, `doc view should sort ascending`) into `group5/_field_data_with_fields_api.ts` **Why:** 4 of 6 tests were byte-for-byte duplicates of tests already in `_field_data_with_fields_api.ts` (php hit count, php highlight, type:apache hit count, bad syntax error). The 2 remaining grid-specific tests were merged into the canonical file, eliminating an entire test file and its setup overhead from the `group2_data_grid2` CI config. --- ### Area 4: Embeddable dashboard round-trip — MERGED WITH SHARED HELPER **Files changed:** - Deleted `src/platform/test/functional/apps/discover/embeddable_2/_esql_embeddable.ts` - Removed its `loadTestFile` entry from `embeddable_2/index.ts` - Restructured `embeddable/_saved_search_embeddable.ts` to add a `describeEditSessionTests` helper that generates 3 edit-session tests (linked edit + return, by-value edit + return, save-as-new) for any panel type - The helper is called twice: once for saved search panels, once for ES|QL panels - Both use the same `discover.getSavedSearchDocumentCount()` assertion (same UI component for both panel types) **Why:** 3 of 4 ES|QL tests repeated the same edit-session navigation contract as the saved-search tests. A shared helper now exercises both panel types with zero code duplication, while each type gets its own test runs to catch type-specific regressions. The 1 unique "add ES|QL panel" smoke test is covered implicitly by the linked-session edit test. --- ### Area 2: Context navigation — REPOSITIONED **Files changed:** - Moved the "should open the context view with the same columns" test in `group2_data_grid1/_data_grid_context.ts` to run **after** the anchor test instead of before it **Why:** Previously this test ran first (on Discover, not on the context view) making it a duplicate of what `context/_discover_navigation.ts` checks. By placing it after the anchor test navigates to context, it now verifies that the **context view** inherited the correct columns — a different and valid assertion. ### Area 5: Sidebar/doc viewer search-flow **Why not changed:** The 8 overlapping test titles test the same *scenarios* (wildcard, fuzzy, etc.) but on completely different UI surfaces with different APIs (`unifiedFieldList.findFieldByName` vs `discover.findFieldByNameOrValueInDocViewer`), different assertion strategies (exact field name arrays vs DOM cell counts), and different expected values (4 vs 3 fields for fuzzy search due to different search corpora). They run on separate CI configs so deduplication saves 0s. A shared helper would be entirely parameters — harder to read than the original tests. ### Area 3: Read-only badge privilege checks **Why not changed:** 2 of 3 files have already been migrated to Scout. The remaining `discover_security.ts` has unique Discover-specific tests (share URLs, CSV export, alias access) with no remaining overlap. ### 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) - [x] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels.
…iToolTip (elastic#271484) Relates to elastic/eui#9566 > [!IMPORTANT] > These changes **should be carefully tested visually by each code owner.** Wrapping with `EuiToolTip` instead of passing `title` leads to another DOM node and can potentially break the layout. In such cases, I would appreciate committing appropriate fixes to this PR directly, I cannot possibly setup and run all Kibana functionalities to fix every regression. This PR: - wraps ALL `EuiButtonIcon` with `EuiToolTip`, the content is the same as `aria-label`, any `title` passed to `EuiButtonIcon` is removed, - changes several `title` cases (not truncation related) to use `EuiToolTip` instead (if applicable). --------- Co-authored-by: Alexey Antonov <alexwizp@gmail.com>
…5151) ## Summary Adds a GitHub Actions workflow that **bulk-triages** open issues carrying the [needs-team](https://github.com/elastic/kibana/issues?q=state%3Aopen%20label%3Aneeds-team&page=1) label (currently 500+ issues which needs to be triaged!). Instead of reacting to individual label events, the workflow runs on a schedule (every hour) and can also be triggered manually via [workflow_dispatch](https://github.com/elastic/kibana-automated-triage/actions/workflows/triage-bulk.yml). It calls the reusable workflow at [`elastic/kibana-automated-triage/.github/workflows/triage-bulk.yml`](https://github.com/elastic/kibana-automated-triage) to suggest team assignments using AI (Gemini). Here is an example run: https://github.com/elastic/kibana-automated-triage/actions/runs/25668944498/job/75348762511 <img width="1583" height="1207" alt="Screenshot 2026-05-11 at 14 15 44" src="https://github.com/user-attachments/assets/830d4bba-64ba-4b31-877d-4ee5c731745a" /> ### How it works | Trigger | Behaviour | |---------|-----------| | `schedule` (hourly cron) | Triages up to 10 open `needs-team` issues per run, skips the ones with low triaging confidence | ### Required secret `GEMINI_KEY_ISSUE_TRIAGE` — Gemini API key (already added to the repo). ### Checklist - [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) - [x] Review the [backport guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-backport-process) and apply applicable `backport:*` labels. ### Identify risks Does this PR introduce any risks? - **Low risk**: The workflow only runs on a cron schedule or manual dispatch, calling an external reusable workflow. No code changes to Kibana itself. If the secret is missing the workflow will simply fail silently. This PR adds internal CI tooling and does not affect end users.
…astic#271759) ## Summary Fixes an incorrect API route path in the `run_script` response action OpenAPI schema. The path was defined as `/api/endpoint/action/runscript` but the correct route is `/api/endpoint/action/run_script`. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary ### What was migrated FTR Configs: - x-pack/platform/test/functional_basic/apps/transform/feature_controls/config.ts - x-pack/platform/test/functional/apps/cross_cluster_replication/config.ts - x-pack/platform/test/functional/apps/index_lifecycle_management/config.ts - x-pack/platform/test/functional/apps/management/config.ts - x-pack/platform/test/functional/apps/transform/feature_controls/config.ts specific FTR Test files: - x-pack/platform/test/functional/apps/api_keys/feature_controls/api_keys_security.ts - x-pack/platform/test/functional/apps/index_management/feature_controls/index_management_security.ts - x-pack/platform/test/functional/apps/license_management/feature_controls/license_management_security.ts - x-pack/platform/test/functional/apps/remote_clusters/feature_controls/remote_clusters_security.ts ### What the deleted FTR tests were doing The feature-controls suites each launched a full browser, loaded a role, navigated to `Stack Management` and checked whether the nav link and section items appeared or were hidden. The same pattern repeated 9 times — once per plugin — with each running sequentially in its own FTR config (separate server boot). The remaining suites tested ILM policy creation/cloning/read-only flows, CCR home page rendering, and the Create Data View wizard — all straightforward UI flows with no role-matrix complexity. ### Coverage after migration Specs | Location | What they cover -- | -- | -- nav_access.spec.ts | management/test/scout/ui/ | Stack Management nav link appears for kibana_admin, absent for global_dashboard_read data_section.spec.ts | management/test/scout/ui/ | Data section items (transform, ILM, CCR, index management) gated by ES cluster privileges other_sections.spec.ts | management/test/scout/ui/ | Ingest (logstash), security (api_keys), stack (license, remote_clusters) section gating ilm_home_page.spec.ts | index_lifecycle_management/test/scout/ui/ | Smoke + multi-phase policy create → flyout → list + unsaved-changes guard ilm_duplicate_managed_policy.spec.ts | index_lifecycle_management/test/scout/ui/ | Cloning a managed policy strips _meta.managed ilm_read_only_view.spec.ts | index_lifecycle_management/test/scout/ui/ | read_ilm user sees list, no create button, can open flyout cross_cluster_replication_home.spec.ts | cross_cluster_replication/test/scout/ui/ | Both tabs and primary action buttons visible with CCR privileges create_data_view_wizard.spec.ts | data_view_editor/test/scout/ui/ | Data stream accepted as source; wizard auto-detects `@timestamp`; save navigates to detail page ### Test coverage parity Every assertion the deleted FTR tests made is still covered: - Role-based nav visibility: the 9 feature-controls suites each checked one section of the sidebar — now consolidated into 3 parametrized Scout specs that run in parallel with `workers: 2`, reusing a single server boot. - ILM flows: all 3 FTR files (`home_page`, `duplicate_managed_policy`, `read_only_view`) migrated 1:1 to Scout. The frozen phase is intentionally omitted (requires path.repo snapshot repository not available in the Scout cluster) — warm + delete phases are sufficient to cover multi-phase creation. - CCR home: all tab/button assertions migrated; the role now correctly includes monitor (required by `ccr.stats()`) and read_ccr (required by `ccr.followInfo()`). - Create Data View wizard: all assertions migrated; fixed a race condition in the FTR version (now waits for `data-is-loading="0"` on the `timestamp` combobox before reading its value). ### CI runtime optimisation **Before (without server start time)** Configs: - x-pack/platform/test/functional_basic/apps/transform/feature_controls/config.ts - 1 min - x-pack/platform/test/functional/apps/cross_cluster_replication/config.ts - 1 min - x-pack/platform/test/functional/apps/index_lifecycle_management/config.ts - 2 min - x-pack/platform/test/functional/apps/management/config.ts - 1 min - x-pack/platform/test/functional/apps/transform/feature_controls/config.ts - 1 min Test files: - x-pack/platform/test/functional/apps/api_keys/feature_controls/api_keys_security.ts - 40s - x-pack/platform/test/functional/apps/index_management/feature_controls/index_management_security.ts - 50s - x-pack/platform/test/functional/apps/license_management/feature_controls/license_management_security.ts - 1 min - x-pack/platform/test/functional/apps/remote_clusters/feature_controls/remote_clusters_security.ts - 50s It takes another 1.5 min to start servers, total runtime per CI build: **17 min** **After (without server start time)** - src/platform/plugins/shared/data_view_editor/test/scout/ui/playwright.config.ts - 29s - src/platform/plugins/shared/management/test/scout/ui/parallel.playwright.config.ts - 52s - x-pack/platform/plugins/private/index_lifecycle_management/test/scout/ui/playwright.config.ts - 39s - x-pack/platform/plugins/private/cross_cluster_replication/test/scout/ui/playwright.config.ts - 33s We will run them in existing lanes due to short runtime and it means no server time to count. total runtime per CI build: **2.5 min**
…ic#271519) - Closes elastic#190293 ## Summary This PR adds highlighting support for ES|QL. <img width="1905" height="866" alt="image" src="https://github.com/user-attachments/assets/d806ccc1-165e-46f6-a7f7-57258ac03191" /> ### How does highlighting work? DSL and ES|QL highlights do not work in the same way: - DSL keeps the value unchanged and return an extra 'highlight' field in the hit that contains substrings to be highlighted. - ES|QL directly inlines the highlighting tags inside the result value, not additional information is received in the result. ### Implementation details In order to leverage the current fields formatter architecture, we decorate the Discover hit with a new `inline_highlights` field when it's detected that the query result has been highlighted. It contains the highlighted columns and which tags has been used for highlighting on each of them (could be different). Then when the field formatter receives the `hit` it can decide which algorithm to use. See elastic#270394 for alternatives discussed. ### 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 - [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: Stratou <efstratia.kalafateli@elastic.co>
…lastic#271468) ## Summary Replace the TaskClient-based onboarding orchestration with an `OnboardingWorkflowClient` that wraps the workflows management API, unifying all KI identification operations (run, status, cancel) behind the managed onboarding workflow (`streams_ki/onboarding.yaml`). ### Key changes - **New `OnboardingWorkflowClient`** — stream-centric interface for running, querying, and canceling KI onboarding workflows. Each stream's execution is keyed by a concurrency group derived from the stream name (ensuring at most one active run per stream). - **New route `POST /internal/streams/{streamName}/onboarding/_execute`** — replaces `_task` with a `discriminatedUnion` body schema supporting `schedule` and `cancel` actions. - **Simplified `OnboardingResult` schema** — flat structure with summary counts (`discoveredFeaturesCount`, `persistedQueriesCount`, etc.) instead of nested `TaskResult` wrappers. - **New `OnboardingStatus` enum** — domain-level statuses (`not_started`, `in_progress`, `being_canceled`, `canceled`, `failed`, `completed`) replacing the generic `TaskStatus`. - **Agent builder tools updated** — all three KI identification tools (`start`, `status`, `cancel`) now accept `OnboardingWorkflowClient` instead of `GetScopedClients`. - **Continuous extraction workflow updated** — calls the new onboarding endpoints and uses `OnboardingWorkflowClient.cancelAllRunning()` for teardown. - **Frontend hooks migrated** — `useKnowledgeIndicatorsTask` → `useKnowledgeIndicatorsOnboarding`, `useOnboardingApi` methods renamed (`scheduleOnboarding`, `getOnboardingStatus`, `cancelOnboarding`). - **Old task definitions deprecated** — `streams_onboarding`, `streams:features-identification`, and `streams:sig-events-queries-generation` task types are annotated `@deprecated` and kept for reference (removal in follow-up). ## Test plan - [ ] **Onboarding from stream details view** — trigger schedule, verify polling shows progress, cancel mid-run, verify final status (Completed/Canceled) - [ ] **Onboarding from discovery view** — bulk-trigger onboarding for multiple streams, verify status indicators update correctly across the tree table - [ ] **Continuous extraction workflow** — enable continuous extraction, verify eligible streams are classified correctly (candidates, already-running, up-to-date, excluded), confirm scheduled workflows complete end-to-end - [ ] **Onboarding with agents** — use `ki_identification_start`, `ki_identification_status`, and `ki_identification_cancel` tools via the agent, verify `execution_id` is returned in status/cancel responses --------- Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
…on with EuiToolTip (elastic#271481) Closes elastic#270161 Relates to elastic/eui#9566 > [!IMPORTANT] > These changes **should be carefully tested visually by each code owner.** Wrapping with `EuiToolTip` instead of passing `title` leads to another DOM node and can potentially break the layout. In such cases, I would appreciate committing appropriate fixes to this PR directly, I cannot possibly setup and run all Kibana functionalities to fix every regression. This PR: - wraps ALL `EuiButtonIcon` with `EuiToolTip`, the content is the same as `aria-label`, any `title` passed to `EuiButtonIcon` is removed, - changes several `title` cases (not truncation related) to use `EuiToolTip` instead (if applicable). --------- Co-authored-by: Alexey Antonov <alexwizp@gmail.com> Co-authored-by: Ania Kowalska <63072419+akowalska622@users.noreply.github.com>
…#271765) Closes elastic#271750 ## Summary - Dashboard filters are not inherited by the service map - Added a few unit tests ### Before and After #### Before https://github.com/user-attachments/assets/c80e0f89-0f30-4187-b059-3f2b9db46396 #### After https://github.com/user-attachments/assets/51bdd0a8-ba33-4919-ab06-9307242075dc ### 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
## Summary Followup to elastic#271465 which missed these strings. ### 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) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added - [ ] 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) - [ ] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels. ### Identify risks UI labels change only. Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
… credential selector (elastic#271805) ## Summary Fixes the consistently failing `cis_integration_gcp.ts` agentless test (elastic#262351). **Root cause:** When GCP Cloud Connectors are enabled (CSP package >= `3.3.0-preview03`), the agentless GCP form now defaults to the `cloud_connectors` credential type, which renders `LazyCloudConnectorSetup` instead of the Launch Cloud Shell button. The test was unconditionally asserting the Cloud Shell button, causing a consistent failure. **Fix:** Add `selectGcpCredentials` and `isGcpCredentialSelectorVisible` page object helpers, then conditionally switch to `credentials-json` before asserting the Cloud Shell button — mirroring the same pattern the AWS test uses with `selectAwsCredentials('direct')`. ## Changes - `add_cis_integration_form_page.ts`: Added `selectGcpCredentials` and `isGcpCredentialSelectorVisible` page object methods - `cis_integration_gcp.ts`: Un-skipped outer `describe.skip`, added conditional credential type selection before asserting Cloud Shell button Note: The inner `describe.skip('Serverless - Agentless CIS_GCP edit flow')` remains skipped (separate issue with `getFieldAttributeValue` returning `[object Object]`). ## 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/packages/kbn-i18n/GUIDELINE.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/) was added for features that require explanation or tutorials - [ ] [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 - [ ] 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 - Low. Only test code changed, no production code. - The fix degrades gracefully: `isGcpCredentialSelectorVisible()` returns false when GCP Cloud Connectors are not enabled (older package), so no credential switch is attempted and the existing assertion continues to work. Made with [Cursor](https://cursor.com) Co-authored-by: Cursor <cursoragent@cursor.com>
elastic#266468) - When Entity Store v2 is on, the Watchlists tab shows a callout if the store is not running (or if status fails to load). - Create Watchlists Button and Management Table stay visible so users can still manage watchlists. - Smol update on props also: Watchlists props optional with defaults for tab usage; table component only receives spaceId (matches its API). For this issue: elastic#266453 **Screenshot:** <img width="2370" height="1440" alt="image" src="https://github.com/user-attachments/assets/d881d55f-f30d-4446-a6fa-d18b1f9861c0" /> --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
…71625) ## Summary Creates `@kbn/ui-chrome-layout-constants` and `@kbn/ui-chrome-layout-utils` as proper kbn-ui packages, replacing the hand-maintained stub files that @kbn/ui-chrome-layout and @kbn/ui-side-navigation previously used at webpack build time. The implementation (CSS variables, layout levels, scroll utilities, and high-contrast helpers) now lives in the kbn-ui tree and is published to Artifactory alongside the other kbn-ui packages. `@kbn/core-chrome-layout-constants` and `@kbn/core-chrome-layout-utils` are retained as thin re-export shims (export * from '@kbn/ui-*') so all existing Kibana consumers continue to work without changes. The publish pipeline is also extended with a topological sort over kbn-ui package dependencies (read from each package's moon.yml) so packages are always built and published in dependency order; each package's build.sh additionally checks and builds missing dependency targets as a safety net for partial runs. **_note for reviewers:_** I've moved the vault address to the previous location as it was still failing in CI --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary This PR resolves [[Scout] Move EUI Provider from FTR to Scout](elastic/kibana-team#3395) issue.
…astic#270348) Closes elastic/rna-program#355 ## Summary Adds optional `version` field to `PATCH /api/alerting/v2/rules/{id}` for optimistic concurrency control, matching the pattern already used by the notification policy update route. Without this, concurrent updates silently use last-write-wins. ## Changes - **Schema**: new `updateRuleBodySchema` extends `updateRuleDataSchema` with optional `version` (`min(1).max(256)`). Added `version` to `ruleResponseSchema`. - **Route**: validates with `updateRuleBodySchema`, destructures `version` into `options`, documents `409`. - **Rules client**: `updateRule` now accepts `options.version`. When provided, the server enforces OCC and returns `409 Conflict` on mismatch via the existing SO conflict mapping. When omitted, falls back to the current server-read version (no breaking change). - **SO service**: `create`, `update`, and `find` contracts widened to surface `version` so it flows through to the response transform. - **Response transform**: `transformRuleSoAttributesToRuleApiResponse` now carries `version` through every read path --------- Co-authored-by: Christos Nasikas <xristosnasikas@gmail.com>
Automated by https://buildkite.com/elastic/package-storage-infra-kibana-discover-release-branches/builds/4920 Co-authored-by: elastic-vault-github-plugin-prod <elasticmachine@elastic.co>
…lastic#271892) Reverts elastic#255151 due to cross-repos access issues as https://github.com/elastic/kibana-automated-triage is a private repo. I will create another workflow which would be triggered directly from https://github.com/elastic/kibana-automated-triage with the same schedule.
…269633) Closes elastic/obs-ai-team#549 ### Summary Fixes a discovery gap where `observability.get_index_info` (`get-index-patterns`) could not see Streams data streams because discovery used `indices.getDataStream` with dash-oriented patterns (`logs-*`), which do not match dot-hierarchy stream names (`logs.aws-lambda-payment-gateway`). The Elastic AI Agent with the investigation skill relies on this tool to learn which indices exist before calling `get_logs`, field discovery, etc. Without it, Streams-ingested data was invisible while `platform.core.list_indices` found everything. ### Changes - Switch data stream discovery `get_data_streams_handler.ts` from `indices.getDataStream` to `listSearchSources` (`_resolve_index`), matching `platform.core.list_indices` - Add Streams hierarchy patterns: - `logs` - `logs.*` - `metrics` - `metrics.*` - `traces` - `traces.*` alongside existing log/metric/APM patterns from `getObservabilityDataSources`. - Extend `extractDataset` to handle dot-hierarchy names: - `logs.ecs.nginx` → `ecs.nginx` while preserving classic Fleet parsing: - `metrics-system.memory-default` → `system.memory` ### Test #### Manual - Ingest via Elastic Streams (e.g. `streams_messy_logs`) - Run Agent Builder with investigation skill - Ask about the data - Agent should call `get_index_info` and see dot-notation streams #### Compare behavior - Compare with `platform.core.list_indices` on the same cluster - Both should list Streams data --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes elastic/obs-ai-team#571 ## Summary **dev golden-cluster Vault path directly usable from `kbn-evals` CLI**. This PR makes the **dev golden-cluster Vault path directly usable from the `kbn-evals` CLI**, without needing to share secrets or maintain local secret files. Developers now have a `dev-vault` profile. ### Changes - Dev Vault profile support in CLI profile resolution: Added/used a virtual profile (`dev-vault`) for runtime Vault reads. - Vault script usability updates: Updated vault scripts (`retrieve/upload/get_command`) with `--vault dev|ci-prod`. ### Manual smoke - `node scripts/evals init` - `node scripts/evals start --suite <suite-id> --profile dev-vault` --------- Co-authored-by: Srdjan Lulic <lulic.ing@gmail.com>
…e review endpoints to support aggregation (elastic#266112) # Summary Migrates the existing `POST /internal/detection_engine/prebuilt_rules/installation/_review` and `POST /internal/detection_engine/prebuilt_rules/upgrade/_review` endpoints to consume the same granular request shape introduced by `rules/_search` (elastic#262307) and to generate their Zod schema from OpenAPI (this is the source of a lot of the diff). Both endpoints now support: - **KQL filtering** via a dedicated `filter.term` / `filter.mode` pair, kept separate from free-text **search** (`search.term` / `search.mode`). - **Facet aggregations** via `aggregations.counts`, returning per-category bucket counts in a single round-trip alongside the page of rules: - install-review: `tags`, `severity` - upgrade-review: `tags`, `enabled`, `isCustomized` (and other `GranularRulesFacetCategory` values supported by the rules search path) - **Field selection** via a `fields` parameter to narrow Elasticsearch `_source` for prebuilt-rule-asset documents (install-review) and to trim `current_rule` / `target_rule` payloads (upgrade-review). A small baseline attribute set is always merged so payloads remain convertible. - **Multi-field `sort`** via an ordered array of `{ field, order }` items. . The Add Elastic Rules and Rule Updates table UIs (`add_prebuilt_rules_table_context.tsx`, `upgrade_prebuilt_rules_table_context.tsx`, `use_prebuilt_rules_install_review.ts`, `use_prebuilt_rules_upgrade_review.ts`, `use_prebuilt_rules_upgrade.tsx`) have been migrated to consume the new endpoint shape, sending the structured KQL filter and search term separately but do not select fields or aggregations as part of this work. The original API design doc can be found [here] (https://docs.google.com/document/d/17jeRzt1a3T4Z3mr2AJqBxyhz_peJRNHL54BUM_AHb7o/edit?tab=t.0#heading=h.pgl8rhsgahc8) (internal). Performance characteristics can be found [here] (https://docs.google.com/document/d/1ZoPAH-OgdUX5WdwFAMLJIuI04PFhU7lqmj2mOmgmlQY/edit?tab=t.0#heading=h.3gyz2zlnp7d1) (internal). # Context The `installation/_review` and `upgrade/_review` endpoints both grew up around a single `filter` object that bundled UI concerns (name, tags, customization status) together. The server re-derived a KQL string on every fetch and, in the case of install-review, pulled the full set of prebuilt-rule assets before narrowing in JavaScript. As the granular filter epic moves forward, that shape no longer scales for filter / search / aggregation extensibility. These endpoints remain internal until the full granular epic has shipped and the contract is stable. # Testing - Start Kibana locally and navigate to Security → Rules → **Add Elastic Rules**. - Confirm the install review table loads correctly — check the Network tab to verify requests go to `POST /internal/detection_engine/prebuilt_rules/installation/_review` and that the body contains `filter`, `search`, and (when sorting) `sort`. - Use the search box and tag filter and verify rules are filtered as expected. - Navigate to Security → Rules → **Rule Updates**. - Confirm the upgrade review table loads correctly via `POST /internal/detection_engine/prebuilt_rules/upgrade/_review` with the same POST body shape, and that filtering by tags, customization status, and free-text search produces the expected results. - Call both endpoints directly via curl or Postman to verify facet counts (`counts.tags`, `counts.severity`, `counts.enabled`, `counts.isCustomized`, etc.) are returned and stay consistent with the filtered set when applied. # Checklist Reviewers should verify this PR satisfies this list as well. - [x] Unit or functional tests were updated or added to match the most common scenarios - [x] [Flaky Test Runner](https://buildkite.com/elastic/kibana-flaky-test-suite-runner) 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) - [x] [Review the backport guidelines](https://www.elastic.co/guide/en/kibana/current/backporting.html) and apply applicable `backport:*` labels --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ution classic nav (elastic#269683) ## Summary Adds Discover, Agents and Workflows app links to classic Security Solution nav to align with the current Security Solution (solutions only nav) Note: Agents links (agent builder) is gated and shows only if the new AI agent experience is active (`app/management/ai/genAiSettings`). <img width="1665" height="530" alt="Screenshot 2026-05-29 at 10 43 10" src="https://github.com/user-attachments/assets/f1f14c9b-b426-4c5a-8064-113551ff5ffc" /> <details><summary>Screenshot</summary> <img width="230" height="794" alt="Screenshot 2026-05-18 at 14 00 04" src="https://github.com/user-attachments/assets/99c252c7-528c-49ff-aafa-5fb8955a3305" /> </details> The changes are gated with `securityClassicNavExternalLinks` feature flag. > [!Note] > There will be a follow up PR to move Agents to the top that would depend on a [separate feature flag ](elastic#267628) ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [ ] 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) - [ ] [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 - [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [ ] 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. - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [ ] 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) - [ ] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels. ### Identify risks Does this PR introduce any risks? For example, consider risks like hard to test bugs, performance regression, potential of data loss. Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging. - [ ] [See some risk examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) - [ ] ...
…RulesPackageInstallation` helper (elastic#271457) Closes elastic#268359, closes elastic#268360, closes elastic#268548, closes elastic#268549, closes elastic#268566, closes elastic#268567, closes elastic#268708, closes elastic#269232, closes elastic#269233, closes elastic#269723, closes elastic#270225, closes elastic#270226, closes elastic#270318, closes elastic#270319, closes elastic#270611, closes elastic#271178, closes elastic#271179, closes elastic#271182, closes elastic#271183, closes elastic#271193, closes elastic#271543, closes elastic#271544. This PR fixes flakiness in Cypress tests that use `preventPrebuiltRulesPackageInstallation` helper. 🟢 Flaky Test Runner: https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/12493 Test used to fail with `Error: Socket closed before finished writing response`. We are using `cy.intercept(...)` to intercept initialization flow requests to skip package installation. However, if initialization request also contains another flow that's unrelated to package installation we don't mock the request. If the non-mocked request is in flight, and during this time Cypress reloads a page (`cy.reload()`), the request gets canceled and Cypress treats it as an error, although it's a normal situation. The fix is using a listener instead of `request.continue(...)`. Listener doesn't error if test runner navigates away – it just doesn't run if response wasn't received. The flakiness was introduced in this PR: elastic#266690 However, the flaky test runner didn't catch it back then because I didn't run all the specs that were affected by the change in helper 🤦♂️. I updated my skill to make sure it triggers the Flaky Test Runner for tests that use a shared helper.
…tic#271547) Resolves elastic#271581 ## Summary - Adds recovery threshold conditions to the threshold rule builder, allowing users to define custom recovery criteria via a guided form - Recovery conditions are auto-derived from alert conditions (flipped comparators) and correctly restored when editing an existing rule - Uses `useBuilderState` context for state management, consistent with the alert condition step (no prop drilling) - Compressed form inputs and consistent spacing across all builder components ## Test plan - [ ] Create a threshold rule, select "Custom recovery", configure conditions, save → verify recovery persists - [ ] Reopen saved rule → verify "Custom recovery" selected with correct conditions - [ ] Switch to "Default recovery" and save → verify recovery resets - [ ] Verify preview does NOT auto-open when selecting "Custom recovery" in builder mode - [ ] Switch default → custom → default → custom → verify conditions re-derive from alert conditions - [ ] Verify non-builder (ES|QL) mode still works as before --------- Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary We agreed to change "Export tab" to "Export tab results" for clarity in Discover's app menu: <img width="500" src="https://github.com/user-attachments/assets/fb7b2e41-00be-43e8-a7bf-fb04037e553c" /> ### 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) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [ ] [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 - [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [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. - [ ] [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) - [x] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels.
Contributor
|
@dej611, this PR increases one or more page-load bundle sizes by 15% or more:
Large bundle size increases can affect page load performance. Consider whether dependencies can be lazy-loaded or code split to reduce the bundle. See the bundle optimization guide for tips. |
Contributor
Author
|
Sorry, bad rebase. will recreate a new clean PR |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This is a proof of concept to have a basic validation layer for workflows examples, extracted from the https://github.com/elastic/workflows repository.
The package can be used for any yaml as well from CLI or imported for a complex use case.
Here's an example of execution locally:
In case of failure the error message is not yet super useful, but it points to the right location at least:
Checklist