## Summary
Switch to one matcher w/ all code owner patterns rather than separate
matchers for each code owner pattern. Reduces the run time of
`scripts/check_ftr_code_owners.js` by ~10x.
### Before
```console
▶ node scripts/check_ftr_code_owners.js
info Reading CODEOWNERS file
info Checking ownership for 8653 test files (this will take a while)
info Ownership check complete (took 18.89 s)
succ All test files have a code owner. 🥳
```
#### After
```console
▶ node scripts/check_ftr_code_owners.js
info Checked 8653 test files in 1.59s
succ All test files have a code owner 🥳
```
> A follow-up to #203879
## Summary
This PR integrates the new Assistant Icon, Beacon, and Avatar into
solutions and packages owned by Security. In most cases this was a 1:1
replacement, but in a few, Icon was replaced with Beacon for
consistency, (e.g. welcome screens, upsells, etc)
Note: the scaling of the icon/avatar _before_ was one different from
EUI. The new components match EUI directly and represent a 2x scale
change (e.g. 's' becomes 'l', 'm' becomes 'xl', etc).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of #140695.
We defined the hex codes for anomaly detection severity colors in
several places. This PR consolidates this and makes sure the hex codes
are defined in just one place. Note this PR doesn't change any of the
colors or styling related to anomaly detection, it is pure refactoring
to make future updates to these colors more easy.
- Renames `BLANK` to `UNKNOWN` to be in line with severity labels.
- Uses `ML_SEVERITY_COLORS.*` in test assertions so future color changes
won't need updating every assertion.
- Migrates all SCSS that made use of severity colors to emotion so it
can reuse `ML_SEVERITY_COLORS`. Therefor the SCSS based severity colors
get removed in this PR.
### 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)
## Summary
Renames `assetInventoryStoreEnabled` -> `assetInventoryUXEnabled`
Follow-up of this PR:
- https://github.com/elastic/kibana/issues/201705
### Motivation
Deviate from `assetInventoryStoreEnabled` which is also used for backend
changes. This gives us more fine-grained control about changes and the
new `assetInventoryUXEnabled` will only be responsible of showing/hiding
the interface.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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)
### Risks
No risk whatsoever
Closes https://github.com/elastic/enhancements/issues/22091
## Summary
The ServiceNow ITSM and SecOps connector for cases now supports the
`Additional fields` JSON field. This is an object where the keys
correspond to the internal names of the table columns in ServiceNow.
## How to test
1. Cases with an existing ServiceNow connector configuration should not
break.
2. The additional fields' validation works as expected.
3. Adding additional fields to the ServiceNow connector works as
expected and these fields are sent to ServiceNow.
Testing can be tricky because ServiceNow ignores additional fields where
the key is not known or the value is not accepted. You need to make sure
the key matches an existing column and that the value is allowed **on
ServiceNow**.
### SecOps
The original issue concerned the fields `Configuration item`, `Affected
user`, and `Location` so these must work.
An example request **for SecOps** with these fields' keys is the
following:
```
{
"u_cmdb_ci": "*ANNIE-IBM",
"u_location": "815 E Street, San Diego,CA",
"u_affected_user": "Antonio Coelho"
}
```
This should result in:
<img width="901" alt="Screenshot 2024-11-27 at 12 52 37"
src="https://github.com/user-attachments/assets/6734a50b-b413-4587-b5e2-2caf2e30ad67">
**The tricky part here is that they should be the names of existing
resources in ServiceNow so the values cannot be arbitrary.**
### ITSM
ITSM fields are different than the ones in SecOps. An example object is:
```
{
"u_assignment_group": "Database"
}
```
This results in:
<img width="1378" alt="Screenshot 2024-11-27 at 13 46 56"
src="https://github.com/user-attachments/assets/8064f882-2ab5-4fd6-b123-90938ab3bb83">
## Release Notes
Pass any field to ServiceNow using the ServiceNow SecOps connector with
a JSON field called "additional fields".
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/203122
## Summary
### Problem
The Obs AI Assistant LLM evaluation framework cannot successfully run in
the current state in the `main` branch and has missing scenarios.
Problems identified:
- Unable to run the evaluation with a local Elasticsearch instance
- Alerts and APM results are skipped entirely when reporting the final
result on the terminal (due to consistent failures in the tests)
- State contaminations between runs makes the script throw errors when
run multiple times.
- Authentication issues when calling `/internal` APIs
### Solution
As a part of spacetime, worked on fixing the current issues in the LLM
evaluation framework and working on improving and enhancing the
framework.
#### Fixes
| Problem | RC (Root Cause) | Fixed? |
|------------------------|---------------------------------|--------|
| Running with a local Elasticsearch instance | Service URLs were not
picking up the correct auth because of the format specified in
`kibana.dev.yml` | ✅ |
| Alerts and APM results skipped in final result | Most (if not all)
tests are failing in the alerts and APM suites, hence no final results
are reported. | ✅ (all test scenarios fixed) |
| State contaminations between runs | Some `after` hooks were not
running successfully because of an error in the `callKibana` method | ✅
|
| Authentication issues when calling `/internal` APIs | The required
headers are not present in the request | ✅ |
#### Enhancements / Improvements
| What was added | How does it enhance the framework |
|------------------------|---------------------------------|
| Added new KB retrieval test to the KB scenario | More scenarios
covered |
| Added new scenario for the `retrieve_elastic_doc` function | Cover
missing newly added functions |
| Enhance how scope is used for each scenario and apply correct scope |
The scope determines the wording of the system message. Certain
scenarios need to be scoped to observability (e.g.: `alerts`) to produce
the best result. At present all scenarios use the scope `all` which is
not ideal and doesn't align with the actual functionality of the AI
Assistant |
| Avoid throwing unnecessary errors on the console (This was fixed by
adding guard rails, e.g.: not creating a dataview if it exists) | Makes
it easier to navigate through the results printed on the terminal |
| Improved readme | Easier to configure and use the framework while
identifying all possible options |
| Improved logging | Easier to navigate through the terminal output |
### 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)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR aims at relocating some of the Kibana modules (plugins and
packages) into a new folder structure, according to the _Sustainable
Kibana Architecture_ initiative.
> [!IMPORTANT]
> * We kindly ask you to:
> * Manually fix the errors in the error section below (if there are
any).
> * Search for the `packages[\/\\]` and `plugins[\/\\]` patterns in the
source code (Babel and Eslint config files), and update them
appropriately.
> * Manually review
`.buildkite/scripts/pipelines/pull_request/pipeline.ts` to ensure that
any CI pipeline customizations continue to be correctly applied after
the changed path names
> * Review all of the updated files, specially the `.ts` and `.js` files
listed in the sections below, as some of them contain relative paths
that have been updated.
> * Think of potential impact of the move, including tooling and
configuration files that can be pointing to the relocated modules. E.g.:
> * customised eslint rules
> * docs pointing to source code
> [!NOTE]
> * This PR has been auto-generated.
> * Any manual contributions will be lost if the 'relocate' script is
re-run.
> * Try to obtain the missing reviews / approvals before applying manual
fixes, and/or keep your changes in a .patch / git stash.
> * Please use
[#sustainable_kibana_architecture](https://elastic.slack.com/archives/C07TCKTA22E)
Slack channel for feedback.
Are you trying to rebase this PR to solve merge conflicts? Please follow
the steps describe
[here](https://elastic.slack.com/archives/C07TCKTA22E/p1734019532879269?thread_ts=1734019339.935419&cid=C07TCKTA22E).
#### 9 packages(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/cbor` | `src/platform/packages/shared/kbn-cbor` |
| `@kbn/repo-info` | `src/platform/packages/shared/kbn-repo-info` |
| `@kbn/repo-packages` |
`src/platform/packages/private/kbn-repo-packages` |
| `@kbn/rison` | `src/platform/packages/shared/kbn-rison` |
| `@kbn/ui-shared-deps-npm` |
`src/platform/packages/private/kbn-ui-shared-deps-npm` |
| `@kbn/ui-shared-deps-src` |
`src/platform/packages/private/kbn-ui-shared-deps-src` |
| `@kbn/ui-theme` | `src/platform/packages/shared/kbn-ui-theme` |
| `@kbn/utility-types-jest` |
`src/platform/packages/shared/kbn-utility-types-jest` |
| `@kbn/utils` | `src/platform/packages/shared/kbn-utils` |
<details >
<summary>Updated references</summary>
```
./kbn_pm/src/lib/bazel.mjs
./kbn_pm/src/lib/external_packages.js
./package.json
./packages/core/rendering/core-rendering-server-internal/src/bootstrap/get_theme_tag.ts
./packages/kbn-babel-register/BUILD.bazel
./packages/kbn-eslint-plugin-imports/src/helpers/groups.ts
./packages/kbn-monaco/BUILD.bazel
./packages/kbn-plugin-helpers/src/tasks/bazel_packages.ts
./packages/kbn-repo-packages/package-map.json
./packages/kbn-ts-projects/config-paths.json
./packages/kbn-ui-shared-deps-npm/BUILD.bazel
./packages/kbn-ui-shared-deps-src/BUILD.bazel
./src/dev/build/tasks/build_packages_task.ts
./src/platform/packages/private/kbn-repo-packages/jest.config.js
./src/platform/packages/private/kbn-repo-packages/package-map.json
./src/platform/packages/private/kbn-ui-shared-deps-src/BUILD.bazel
./src/platform/packages/shared/kbn-cbor/jest.config.js
./src/platform/packages/shared/kbn-repo-info/jest.config.js
./src/platform/packages/shared/kbn-rison/jest.config.js
./src/platform/packages/shared/kbn-utils/jest.config.js
./tsconfig.base.json
./yarn.lock
.github/CODEOWNERS
```
</details><details >
<summary>Updated relative paths</summary>
```
src/platform/packages/private/kbn-repo-packages/jest.config.js:12
src/platform/packages/private/kbn-repo-packages/tsconfig.json:2
src/platform/packages/private/kbn-ui-shared-deps-npm/tsconfig.json:2
src/platform/packages/private/kbn-ui-shared-deps-src/tsconfig.json:2
src/platform/packages/shared/kbn-cbor/jest.config.js:12
src/platform/packages/shared/kbn-cbor/tsconfig.json:12
src/platform/packages/shared/kbn-cbor/tsconfig.json:2
src/platform/packages/shared/kbn-repo-info/jest.config.js:12
src/platform/packages/shared/kbn-repo-info/tsconfig.json:2
src/platform/packages/shared/kbn-rison/jest.config.js:12
src/platform/packages/shared/kbn-rison/tsconfig.json:2
src/platform/packages/shared/kbn-ui-theme/tsconfig.json:2
src/platform/packages/shared/kbn-utility-types-jest/tsconfig.json:2
src/platform/packages/shared/kbn-utils/jest.config.js:12
src/platform/packages/shared/kbn-utils/tsconfig.json:2
```
</details>
---------
Co-authored-by: Alex Szabo <alex.szabo@elastic.co>
Co-authored-by: Jonathan Budzenski <jon@elastic.co>
Co-authored-by: Michael Dokolin <mikhail.dokolin@elastic.co>
FTR dependencies needs to be kept up to date across all branches, but
using the backport automation ends up requiring manual intervention due
to merge conflicts.
This configures renovate to open separate pull requests per branch for
the `ftr` group. If this works as expected I'll do another pass and see
if there's other groups that this makes sense for.
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| docker.elastic.co/wolfi/chainguard-base | digest | `3a6e913` ->
`eef54b3` |
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Renovate
Bot](https://togithub.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM3LjQyNS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOk9wZXJhdGlvbnMiLCJyZWxlYXNlX25vdGU6c2tpcCJdfQ==-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
## Summary
https://github.com/elastic/kibana/issues/202505
### Running Kibana with the Borealis theme
In order to run Kibana with Borealis, you'll need to do the following:
Set the following in kibana.dev.yml:
uiSettings.experimental.themeSwitcherEnabled: true
Run Kibana with the following environment variable set:
KBN_OPTIMIZER_THEMES="borealislight,borealisdark,v8light,v8dark" yarn
start
This will expose a toggle under Stack Management > Advanced Settings >
Theme version, which you can use to toggle between Amsterdam and
Borealis.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Part of https://github.com/elastic/kibana/issues/203716
## Summary
* Functional test for verifying that users can create indices using the
“logsdb” index mode via the Kibana interface (Stateful and serverless).
* Functional test for verifying that users can upgrade a logs data
stream that is using a “standard” index mode to a data stream using
“logsdb” index mode. (Stateful and serverless).
* Functional test for verifying that users can downgrade a data stream
that is using a “logsdb” index mode to a data stream using “standard”
index mode. (Stateful and serverless).
* Functional test for verifying that users can upgrade a data stream
that is using a “time series” index mode to a data stream using “logsdb”
index mode. (Stateful and serverless).
* Functional test for verifying that users can downgrade a data stream
that is using a “logsdb” index mode to a data stream using “time series”
index mode. (Stateful and serverless).
The rollover operation has not been tested since is not expected to
happen automatically. See [this
comment](https://github.com/elastic/kibana/issues/203716#issuecomment-2554491054).
This adds a daily build that runs tests again
`docker.elastic.co/package-registry/distribution:lite` and if
successful, promotes the image to
`docker.elastic.co/kibana-ci/package-registry-distribution:lite`.
A follow up pull request will swap integration tests over to use the
promoted image, and add environment overrides to run tests against the
source image in this pipeline.
https://buildkite.com/elastic/kibana-package-registry-promote/builds/2
This PR migrates test suites that use `renderHook` from the library
`@testing-library/react-hooks` to adopt the equivalent and replacement
of `renderHook` from the export that is now available from
`@testing-library/react`. This work is required for the planned
migration to react18.
## Context
In this PR, usages of `waitForNextUpdate` that previously could have
been destructured from `renderHook` are now been replaced with `waitFor`
exported from `@testing-library/react`, furthermore `waitFor`
that would also have been destructured from the same renderHook result
is now been replaced with `waitFor` from the export of
`@testing-library/react`.
***Why is `waitFor` a sufficient enough replacement for
`waitForNextUpdate`, and better for testing values subject to async
computations?***
WaitFor will retry the provided callback if an error is returned, till
the configured timeout elapses. By default the retry interval is `50ms`
with a timeout value of `1000ms` that
effectively translates to at least 20 retries for assertions placed
within waitFor. See
https://testing-library.com/docs/dom-testing-library/api-async/#waitfor
for more information.
This however means that for person's writing tests, said person has to
be explicit about expectations that describe the internal state of the
hook being tested.
This implies checking for instance when a react query hook is being
rendered, there's an assertion that said hook isn't loading anymore.
In this PR you'd notice that this pattern has been adopted, with most
existing assertions following an invocation of `waitForNextUpdate` being
placed within a `waitFor`
invocation. In some cases the replacement is simply a `waitFor(() => new
Promise((resolve) => resolve(null)))` (many thanks to @kapral18, for
point out exactly why this works),
where this suffices the assertions that follow aren't placed within a
waitFor so this PR doesn't get larger than it needs to be.
It's also worth pointing out this PR might also contain changes to test
and application code to improve said existing test.
### What to do next?
1. Review the changes in this PR.
2. If you think the changes are correct, approve the PR.
## Any questions?
If you have any questions or need help with this PR, please leave
comments in this PR.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
When a user profile is not available, the favorites (starred) service
can't be used. On UI user profile can be not available if security is
disabled or for an anonymous user.
This PR improves the handling of starred features for rare cases when a
profile is missing:
- No unnecessary `GET favorites` requests that would fail with error and
add noise to console/networks
- No unhandled errors are thrown
- Starred tab in esql is hidden
- The Dashboard Starred tab isn't flickering on each attempt to fetch
favorites
For this needed to expose `userProfile.enabled$` from core, also created
https://github.com/elastic/kibana/issues/204570
### Testing
```
node scripts/functional_tests_server.js --config test/functional/apps/dashboard/group4/config.ts
localhost:5620
```
another way is by configuring an anonymous user
https://www.elastic.co/guide/en/elasticsearch/reference/current/anonymous-access.html
## Summary
Small fix to the Schema Editor page after the changes in
https://github.com/elastic/kibana/pull/204671.
(Without this mapped fields won't be displayed as we use a read stream
definition).
This PR migrates test suites that use `renderHook` from the library
`@testing-library/react-hooks` to adopt the equivalent and replacement
of `renderHook` from the export that is now available from
`@testing-library/react`. This work is required for the planned
migration to react18.
## Context
In this PR, usages of `waitForNextUpdate` that previously could have
been destructured from `renderHook` are now been replaced with `waitFor`
exported from `@testing-library/react`, furthermore `waitFor`
that would also have been destructured from the same renderHook result
is now been replaced with `waitFor` from the export of
`@testing-library/react`.
***Why is `waitFor` a sufficient enough replacement for
`waitForNextUpdate`, and better for testing values subject to async
computations?***
WaitFor will retry the provided callback if an error is returned, till
the configured timeout elapses. By default the retry interval is `50ms`
with a timeout value of `1000ms` that
effectively translates to at least 20 retries for assertions placed
within waitFor. See
https://testing-library.com/docs/dom-testing-library/api-async/#waitfor
for more information.
This however means that for person's writing tests, said person has to
be explicit about expectations that describe the internal state of the
hook being tested.
This implies checking for instance when a react query hook is being
rendered, there's an assertion that said hook isn't loading anymore.
In this PR you'd notice that this pattern has been adopted, with most
existing assertions following an invocation of `waitForNextUpdate` being
placed within a `waitFor`
invocation. In some cases the replacement is simply a `waitFor(() => new
Promise((resolve) => resolve(null)))` (many thanks to @kapral18, for
point out exactly why this works),
where this suffices the assertions that follow aren't placed within a
waitFor so this PR doesn't get larger than it needs to be.
It's also worth pointing out this PR might also contain changes to test
and application code to improve said existing test.
### What to do next?
1. Review the changes in this PR.
2. If you think the changes are correct, approve the PR.
## Any questions?
If you have any questions or need help with this PR, please leave
comments in this PR.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
* Support packages that are currently placed under a `*/plugins/*`
folder (and viceversa).
* Transform (simplify) the following path:
```
src/platform/packages/shared/chart_expressions/common
# becomes
src/platform/packages/shared/chart-expressions-common
```
cc @markov00
## Summary
Part of https://github.com/elastic/kibana/issues/204761 . This package
is used by every app and I thought it is worth adding it to the shared
bundle. Especially since it is already part of Bazel.
