# Backport
This will backport the following commits from `main` to `8.10`:
- [[Observability AI Assistant] More specific error handling
(#165068)](https://github.com/elastic/kibana/pull/165068)
<!--- Backport version: 8.9.8 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Dario
Gieselaar","email":"dario.gieselaar@elastic.co"},"sourceCommit":{"committedDate":"2023-08-30T07:34:02Z","message":"[Observability
AI Assistant] More specific error handling (#165068)\n\nImplements more
specific error handling, in addition to a bug fix w/ the\r\nLens
function where it was not rendering outside of the Observability
AI\r\nAssistant plugin's context, and validation of the parameters
before\r\nexecuting the function.\r\n\r\nAdditionally:\r\n- improves
recall function\r\n- filter alerts and services by alert/health
status\r\n\r\n---------\r\n\r\nCo-authored-by: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"c5c6574592ee2b88f48454b8ad6d23229bdafab2","branchLabelMapping":{"^v8.11.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:APM","release_note:skip","v8.10.0","v8.11.0"],"number":165068,"url":"https://github.com/elastic/kibana/pull/165068","mergeCommit":{"message":"[Observability
AI Assistant] More specific error handling (#165068)\n\nImplements more
specific error handling, in addition to a bug fix w/ the\r\nLens
function where it was not rendering outside of the Observability
AI\r\nAssistant plugin's context, and validation of the parameters
before\r\nexecuting the function.\r\n\r\nAdditionally:\r\n- improves
recall function\r\n- filter alerts and services by alert/health
status\r\n\r\n---------\r\n\r\nCo-authored-by: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"c5c6574592ee2b88f48454b8ad6d23229bdafab2"}},"sourceBranch":"main","suggestedTargetBranches":["8.10"],"targetPullRequestStates":[{"branch":"8.10","label":"v8.10.0","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v8.11.0","labelRegex":"^v8.11.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/165068","number":165068,"mergeCommit":{"message":"[Observability
AI Assistant] More specific error handling (#165068)\n\nImplements more
specific error handling, in addition to a bug fix w/ the\r\nLens
function where it was not rendering outside of the Observability
AI\r\nAssistant plugin's context, and validation of the parameters
before\r\nexecuting the function.\r\n\r\nAdditionally:\r\n- improves
recall function\r\n- filter alerts and services by alert/health
status\r\n\r\n---------\r\n\r\nCo-authored-by: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"c5c6574592ee2b88f48454b8ad6d23229bdafab2"}}]}]
BACKPORT-->
# Backport
This will backport the following commits from `main` to `8.10`:
- [[Ops] Upgrade to axios 1.4
(#163732)](https://github.com/elastic/kibana/pull/163732)
<!--- Backport version: 8.9.7 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Alex
Szabo","email":"alex.szabo@elastic.co"},"sourceCommit":{"committedDate":"2023-08-22T09:47:48Z","message":"[Ops]
Upgrade to axios 1.4 (#163732)\n\n## Summary\r\nupgrade `axios` to
1.4\r\n\r\n- adjust to header usage, and config optionality\r\n- Axios'
adapters are now resolved from a string key by axios, no need\r\nto
import/instantiate adapters\r\n- most of the changed code stems from
changes in Axios' types\r\n - `response.config` is now optional\r\n-
there was a change in the type of AxiosHeaders
<->\r\nInternalAxiosHeaders\r\n\r\nCloses: #162661 \r\nCloses:
#162414\r\n\r\n---------\r\n\r\nCo-authored-by: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"9d2696b5c5159870cecf02c9f23090b26c924c87","branchLabelMapping":{"^v8.11.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Operations","Team:APM","release_note:skip","backport:prev-MAJOR","v7.17.13","v8.11.0"],"number":163732,"url":"https://github.com/elastic/kibana/pull/163732","mergeCommit":{"message":"[Ops]
Upgrade to axios 1.4 (#163732)\n\n## Summary\r\nupgrade `axios` to
1.4\r\n\r\n- adjust to header usage, and config optionality\r\n- Axios'
adapters are now resolved from a string key by axios, no need\r\nto
import/instantiate adapters\r\n- most of the changed code stems from
changes in Axios' types\r\n - `response.config` is now optional\r\n-
there was a change in the type of AxiosHeaders
<->\r\nInternalAxiosHeaders\r\n\r\nCloses: #162661 \r\nCloses:
#162414\r\n\r\n---------\r\n\r\nCo-authored-by: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"9d2696b5c5159870cecf02c9f23090b26c924c87"}},"sourceBranch":"main","suggestedTargetBranches":["7.17"],"targetPullRequestStates":[{"branch":"7.17","label":"v7.17.13","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v8.11.0","labelRegex":"^v8.11.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/163732","number":163732,"mergeCommit":{"message":"[Ops]
Upgrade to axios 1.4 (#163732)\n\n## Summary\r\nupgrade `axios` to
1.4\r\n\r\n- adjust to header usage, and config optionality\r\n- Axios'
adapters are now resolved from a string key by axios, no need\r\nto
import/instantiate adapters\r\n- most of the changed code stems from
changes in Axios' types\r\n - `response.config` is now optional\r\n-
there was a change in the type of AxiosHeaders
<->\r\nInternalAxiosHeaders\r\n\r\nCloses: #162661 \r\nCloses:
#162414\r\n\r\n---------\r\n\r\nCo-authored-by: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"9d2696b5c5159870cecf02c9f23090b26c924c87"}}]}]
BACKPORT-->
Co-authored-by: Alex Szabo <alex.szabo@elastic.co>
## Risk engine initialisation, update from legacy risk engine workflow
and status change
dfb75d4a-f447-4346-9760-d0e9685cce39
Green areas it is what was implemented
<img width="1449" alt="Screenshot 2023-08-01 at 15 07 01"
src="4d87887f-1163-45eb-a4e9-a77a685f6565">
This pr has:
- Upgrade workflow. If the user has a risk host or user transforms, we
will show the panel with a call to action for the upgrade.
- Introduce new Saved object to save the configuration of risk engine
- API which is described bellow
It required experiment enabled - **riskScoringRoutesEnabled**
## New API
### /engine/status
#### GET
Get the status of the Risk Engine
##### Description:
Returns the status of both the legacy transform-based risk engine, as
well as the new risk engine
##### Responses
```json
{
"legacy_risk_engine_status": "NOT_INSTALLED" , "ENABLED"
,
"risk_engine_status": "NOT_INSTALLED" , "ENABLED" , "DISABLED"
}
```
### /engine/init
#### POST
Initialize the Risk Engine
##### Description:
Initializes the Risk Engine by creating the necessary indices and
mappings, removing old transforms, creating saved object configuration
##### Responses
```json
{
"result": {
"risk_engine_enabled": true,
"risk_engine_resources_installed": true,
"risk_engine_configuration_created": true,
"legacy_risk_engine_disabled": true,
"errors": [
"string"
]
}
}
```
### /engine/enable
#### POST
Enable the Risk Engine
##### Description:
Change saved object configuration and in the future here we will start
task
### /engine/disable
#### POST
Disable the Risk Engine
Change saved object configuration and in the future here we will stop
task
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Ryland Herrick <ryalnd@gmail.com>
## Summary
Since we already have some E2E tests running for serverless, this PR
turns on the internal API restriction flag to test whether our UI
functions _as such_ under these tests.
An alternative could be to have a specific smoke test for this, but it
seems this is thoroughly covered by piggy-backing off the existing set
of tests.
Blocks: https://github.com/elastic/kibana/pull/162149
> Pre-req for https://github.com/elastic/kibana/issues/56406
## Summary
We've had a long-standing problem in Kibana around our use of React
context, particularly with EUI and i18n. There hasn't existed an
idempotent context structure, and that has lead to a lot of unexpected
results, (e.g. missing translations, inconsistent dark mode, excess
context providers, etc).
The biggest change coming from this PR is knowing exactly which provider
to use in a particular use case. This means, for example,
`ReactDOM.render` calls won't be missing `i18n` or `theme` due to a
missing context. It also allows consumers to use `darkMode` without
having to read the `uiSetting` themselves, instead allowing the context
to do it for them.
We also haven't been honoring the intended [`EuiProvider`
API](https://eui.elastic.co/#/utilities/provider#theming-and-global-styles)...
in some cases we've been creating and re-creating the Emotion caches,
often by copy/paste of the cache code. We've also been nesting
`EuiThemeProvider` contexts unnecessarily-- thinking we need to render a
theme provider in an isolated component-- which renders an additional
`span` element into the DOM.
This PR attempts to address this inconsistency by creating a set of
context providers divided by use case:
### `KibanaRootContextProvider`
A root context provider for Kibana. This is the top level context
provider that wraps the entire application. It is responsible for
initializing all of the other contexts and providing them to the
application. It's provided as a package for specific use cases, (e.g.
the `RenderingService`, cases where we replace the entire page content,
Storybook, testing, etc), but not intended for plugins.
### `KibanaRenderContextProvider`
A render context provider for Kibana. This context is designed to be
used with ad-hoc renders of React components, (usually with
`ReactDOM.render`).
### `KibanaThemeContextProvider`
A theme context provider for Kibana. A corollary to EUI's
`EuiThemeProvider`, it uses Kibana services to ensure the EUI Theme is
customized correctly.
### (deprecated) `KibanaStyledComponentsThemeProvider`
A styled components theme provider for Kibana. This package is supplied
for compatibility with legacy code, but should not be used in new code.
## Deprecation strategy
This PR does *not* change any use of context by consumers. It maps the
existing contexts in `kibanaReact` to the new contexts, (along with the
loose API). This means that we won't have completely fixed all of our
dark mode issues yet. But this is necessary to keep this PR focused on
the change, rather than drawing in a lot of teams to review individual
uses.
We should, however, see an immediate performance improvement in the UI
from the reduction in `EuiProvider` calls.
## Open questions
- [ ] Does it make sense to expose a `useTheme` hook from
`@kbn/react-kibana-context-theme` to replace `useEuiTheme`?
## Next steps
- [ ] Update deprecated uses to new contexts.
- [ ] Audit and update calls to `ReactDOM.render`.
- [ ] Add ESLint rule to warn for use of EUI contexts.
- [ ] Delete code from `kibanaReact`.
This PR adds the `Blob` polyfill into the jest jsdom env which is
currently not supported as mentioned in
https://github.com/jsdom/jsdom/issues/2555
---------
Co-authored-by: Thomas Watson <w@tson.dk>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Partially addresses https://github.com/elastic/kibana/issues/159590
## Summary
This PR adds an an internal uiSettings API that is a duplicate of the
public API and is intended for use by the browser-side uiSettings
client.
The PR also adds a config settings that is configured in serverless
context only and exposes the public uiSettings routes based on the value
of this setting (it defaults to false since we don't want to expose the
public routes in serverless).
**How to test:**
I. Verify that in serverless the internal routes are exposed but the
public ones aren't:
1. Start Es with `yarn es snapshot` and Kibana with `yarn
serverless-{mode}` where `{mode}` can be `es`, `oblt`, or `security`
(the public routes should be disabled for all projects).
2. Verify that the public endpoints are not accessible. For example,
`curl --user elastic:changeme
'http://localhost:5601/zhb/api/kibana/settings' -X 'GET'` should return
`{"statusCode":404,"error":"Not Found","message":"Not Found"}`.
3. Verify that the internal endpoints are accessible. For example, `curl
--user elastic:changeme
'http://localhost:5601/zhb/internal/kibana/settings' -X 'GET'` should
return
`{"settings":{"buildNum":{"userValue":9007199254740991},"isDefaultIndexMigrated":{"userValue":true},"defaultRoute":{"isOverridden":true,"userValue":"/app/elasticsearch"}}}`
II. Verify that the both public and internal routes are exposed in
self-managed:
1. Start Es with `yarn es snapshot` and Kibana with `yarn start`
2. Verify that the public endpoints are accessible. For example, `curl
--user elastic:changeme 'http://localhost:5601/zhb/api/kibana/settings'
-X 'GET'` should return
`{"settings":{"buildNum":{"userValue":9007199254740991},"isDefaultIndexMigrated":{"userValue":true}}}`
3. Verify that the internal endpoints are accessible. For example, `curl
--user elastic:changeme
'http://localhost:5601/zhb/internal/kibana/settings' -X 'GET'` should
return
`{"settings":{"buildNum":{"userValue":9007199254740991},"isDefaultIndexMigrated":{"userValue":true}}}`
III. Verify that the plugins/services that consume the internal
uiSettings endpoints work as expected in both self-managed and
serverless environment.
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](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
Running FTR tests locally (not on CI) that make API requests to public
versioned Kibana endpoints is currently broken. This is because:
* we require version headers to be set for both internal and **public**
endpoints in **dev** by way of a runtime check (ensures our code is
locked to a version)
* the vast majority of FTR tests do not set these headers for talking to
public endpoints
* on CI, this is different as we run these tests against a distributable
build (i.e., non-dev)
This manifests locally as a 400 response. E.g. the current
api_integration tests for data views by running:
```
node scripts/functional_test_runner.js --config ./test/api_integration/config.js --grep 'index_pattern_crud'
```
---
There are a few ways to resolve this, this PR proposes that we:
* Keep FTR tests as they are (i.e., don't update all of them to set
headers when making requests to public versioned endpoints), this is a
useful way to exercise our intended end-user behaviour
* Make the version resolution behaviour not depend on `--dev`: rather
set the default resolution to `none` (new setting) when we run in
`--dev` so that it can be configured to behave as we want for tests.
In this way we keep the runtime check for its intended purpose and can
run our FTR tests "as end users" of our endpoints.
---
Close https://github.com/elastic/kibana/issues/161435
## Summary
This PR fixes few issues occurring while running FTR API tests against
actual serverless project.
How to run:
```
TEST_CLOUD=1 ES_SECURITY_ENABLED=1 NODE_TLS_REJECT_UNAUTHORIZED=0 TEST_ES_URL=<your_es_url_with_credentials> TEST_KIBANA_URL=<your_es_url_with_credentials> node --no-warnings scripts/functional_test_runner --es-version=8.9.0 --config x-pack/test_serverless/api_integration/test_suites/search/config.ts --bail
```
The first error is faced during Elasticsearch version validation
```
ERROR Error: attempted to use the "es" service to fetch Elasticsearch version info but the request failed: ResponseError: {"ok":false,"message":"Unknown resource."}
at SniffingTransport.request (/Users/dmle/github/kibana/node_modules/@elastic/transport/src/Transport.ts:535:17)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at Client.InfoApi [as info] (/Users/dmle/github/kibana/node_modules/@elastic/elasticsearch/src/api/api/info.ts:60:10)
at FunctionalTestRunner.validateEsVersion (functional_test_runner.ts:129:16)
at functional_test_runner.ts:64:11
at FunctionalTestRunner.runHarness (functional_test_runner.ts:251:14)
at FunctionalTestRunner.run (functional_test_runner.ts:48:12)
at log.defaultLevel (cli.ts:112:32)
at run.ts:70:7
at withProcRunner (with_proc_runner.ts:29:5)
at run (run.ts:69:5)
at FunctionalTestRunner.validateEsVersion (functional_test_runner.ts:131:13)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at functional_test_runner.ts:64:11
at FunctionalTestRunner.runHarness (functional_test_runner.ts:251:14)
at FunctionalTestRunner.run (functional_test_runner.ts:48:12)
at log.defaultLevel (cli.ts:112:32)
at run.ts:70:7
at withProcRunner (with_proc_runner.ts:29:5)
at run (run.ts:69:5)
```
Since there is no version term in case of serverless, we can skip
version check by using newly added to FTR schema `serverless` property
(`false` by default). It is set to `true` in root FTR config
`/shared/config.base`.
The next error is related to ESArchiver relying on `ES` FTR service to
provide ESClient.
```
ResponseError: security_exception
│ Root causes:
│ security_exception: unable to authenticate user [system_indices_superuser] for REST request [/kibana_sample_data_flights]
```
It is fixed by using the default user (from host url) instead of
`system_indices_superuser` we use in stateful run.
## Summary
> **Note**
> For testing: enable the `agentTamperProtectionEnabled` feature flag.
This PR modifies the quite new `GET /api/fleet/uninstall_tokens` API:
- `GET /api/fleet/uninstall_tokens`, returns token 'metadata' (i.e.
**uninstall token id**, policy ID and creation date) for the latest
token for every policy, without the token itself.
- it is paginated (query params `page`, `perPage`),
- and can be searched by partial policy ID (query param `policyId`).
- this route is not used at the moment, will be used very soon
- `GET /api/fleet/uninstall_tokens/{id}` returns one decrypted token
identified by its ID
- ~`GET /api/fleet/agent_policies/{policyId}/uninstall_tokens`, returns
the decrypted token history for one policy~
- ~this route is used by the `UninstallCommandFlyout`~
- this was added and then removed, because not a necessity at the
moment, and let's keep open all doors for agent tampering v2
### Todo - done ✅
`created_at` field was removed from the uninstall token saved object
mapping (21855ce37b320e1864c5b9db647ac2355158f91d), because it was
unused and messed up ordering by the saved object's own `created_at`
field.
This removal is not allowed, though, so this issue needs to be fixed.
**Update:** after a discussion with Kibana Core team, the `created_at`
field was removed in a separate PR which is merged in v8.9.0. Reason:
it's okay to use the SO's internal `created_at` field for sorting. Also,
the mapping will be released in v8.9.0 first, so it's okay to modify it
this time. The PR: https://github.com/elastic/kibana/pull/159985
### Checklist
Delete any items that are not applicable to this PR.
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
[](https://renovatebot.com)
This PR contains the following updates:
| Package | Change | Age | Adoption | Passing | Confidence |
|---|---|---|---|---|---|
| [elastic-apm-node](https://togithub.com/elastic/apm-agent-nodejs) |
[`^3.46.0` ->
`^3.47.0`](https://renovatebot.com/diffs/npm/elastic-apm-node/3.46.0/3.47.0)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
---
### Release Notes
<details>
<summary>elastic/apm-agent-nodejs</summary>
###
[`v3.47.0`](https://togithub.com/elastic/apm-agent-nodejs/releases/tag/v3.47.0)
[Compare
Source](https://togithub.com/elastic/apm-agent-nodejs/compare/v3.46.0...v3.47.0)
For more information, please see the
[changelog](https://www.elastic.co/guide/en/apm/agent/nodejs/current/release-notes-3.x.html#release-notes-3.47.0).
##### Elastic APM Node.js agent layer ARNs
|Region|ARN|
|------|---|
|af-south-1|arn:aws:lambda:af-south-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|ap-east-1|arn:aws:lambda:ap-east-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|ap-northeast-1|arn:aws:lambda:ap-northeast-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|ap-northeast-2|arn:aws:lambda:ap-northeast-2:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|ap-northeast-3|arn:aws:lambda:ap-northeast-3:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|ap-south-1|arn:aws:lambda:ap-south-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|ap-southeast-1|arn:aws:lambda:ap-southeast-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|ap-southeast-2|arn:aws:lambda:ap-southeast-2:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|ap-southeast-3|arn:aws:lambda:ap-southeast-3:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|ca-central-1|arn:aws:lambda:ca-central-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|eu-central-1|arn:aws:lambda:eu-central-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|eu-north-1|arn:aws:lambda:eu-north-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|eu-south-1|arn:aws:lambda:eu-south-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|eu-west-1|arn:aws:lambda:eu-west-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|eu-west-2|arn:aws:lambda:eu-west-2:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|eu-west-3|arn:aws:lambda:eu-west-3:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|me-south-1|arn:aws:lambda:me-south-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|sa-east-1|arn:aws:lambda:sa-east-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|us-east-1|arn:aws:lambda:us-east-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|us-east-2|arn:aws:lambda:us-east-2:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|us-west-1|arn:aws:lambda:us-west-1:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
|us-west-2|arn:aws:lambda:us-west-2:267093732750:layer:elastic-apm-node-ver-3-47-0:1|
</details>
---
### 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 [Mend
Renovate](https://www.mend.io/free-developer-tools/renovate/). View
repository job log
[here](https://developer.mend.io/github/elastic/kibana).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNS4xMzEuMCIsInVwZGF0ZWRJblZlciI6IjM1LjEzMS4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9-->
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: pgayvallet <pierre.gayvallet@elastic.co>
This PR addresses Cypress parallelisation in Security Solution scope. It
is a first step in improving e2e tests reliability and gives us a solid
foundation for further work on flakiness and run times. With this PR
each CI job starts 3 instances of ES, kibana and Cypress runner in
isolation.
Other issues addressed in this PR:
- Use click() instead of trigger('click') in all Cypress tests.
- Use testIsolation in all Cypress tests.
- login before each test to ensure that the correct user is always
logged in. Also, with test isolation enabled, login should be required
before each test.
- use visit() instead of cy.visit() in some cases so that tests wait for
the page to fully load before executing.
- Cypress e2e tests are no longer compatible with Firefox (or any
non-Chromium based browser) due to using cypress-real-events
- Removes uses of cypress-pipe. Tests that used cypress-pipe in order to
retry click events will no longer retry click events.
- Fixes an error related to test files being overwritten by Webpack file
processing
---------
Co-authored-by: Patryk Kopycinski <contact@patrykkopycinski.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
While elastic/appex-qa is in process to take ownership over FTR related
code, from elastic/kibana-operations it will be good to keep track on
any changes happening and participate in the review process.
## Summary
This
[failure](https://buildkite.com/elastic/kibana-on-merge/builds/29091#01879988-ecd2-4e4f-bfb4-108939f145a1)
clearly shows that `--bail` flag is ignored when passed to
`scripts/functional_tests.js` script, and since
`scripts/functional_tests.js --help` list these flags I think we need to
fix it:
```
--include-tag Tags that suites must include to be run, can be included multiple times
--exclude-tag Tags that suites must NOT include to be run, can be included multiple times
--include Files that must included to be run, can be included multiple times
--exclude Files that must NOT be included to be run, can be included multiple times
--grep Pattern to select which tests to run
--bail Stop the test run at the first failure
--dry-run Report tests without executing them
--updateBaselines Replace baseline screenshots with whatever is generated from the test
--updateSnapshots Replace inline and file snapshots with whatever is generated from the test
```
I was able to reproduce it locally:
1. Break
[test/functional/apps/console/_console.ts](test/functional/apps/console/_console.ts)
by adding `expect(1).to.be(2);` in the first `it` function
2. Run `node scripts/functional_tests.js --bail --config
test/functional/apps/console/config.ts`
Actual: Tests continue to run after failure
Expected: Stop tests after first failure
It turned out `scripts/functional_test_runner.js` respects the flags so
I just copied the logic from
[packages/kbn-test/src/functional_test_runner/cli.ts](https://github.com/elastic/kibana/blob/main/packages/kbn-test/src/functional_test_runner/cli.ts#L41-L63)
Let me know if you think we need to add jest tests.
Tested:
```
node scripts/functional_tests.js --bail --config test/functional/apps/console/config.ts --grep "multiple requests output"
```
Fixes https://github.com/elastic/kibana/issues/149344
This PR migrates all plugins to packages automatically. It does this
using `node scripts/lint_packages` to automatically migrate
`kibana.json` files to `kibana.jsonc` files. By doing this automatically
we can simplify many build and testing procedures to only support
packages, and not both "packages" and "synthetic packages" (basically
pointers to plugins).
The majority of changes are in operations related code, so we'll be
having operations review this before marking it ready for review. The
vast majority of the code owners are simply pinged because we deleted
all `kibana.json` files and replaced them with `kibana.jsonc` files, so
we plan on leaving the PR ready-for-review for about 24 hours before
merging (after feature freeze), assuming we don't have any blockers
(especially from @elastic/kibana-core since there are a few core
specific changes, though the majority were handled in #149370).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Follow-up of https://github.com/elastic/kibana/pull/149188
- Use the bulkDelete API for `KbnClientSavedObjects.bulkDelete`
- Create a dedicated `/_clean` endpoint for
`KbnClientSavedObjects.clean` and
`KbnClientSavedObjects.cleanStandardList`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/kibana/issues/148412
More and more SO types will not be accessible from the HTTP APIs (either
`hidden:true` or `hiddenFromHTTPApis: true`).
However, the FTR SO client (`KbnClientSavedObjects`) still needs to be
able to access and manipulate all SO types.
This PR introduces a `ftrSoApis` plugin that is loaded for all FTR
suites. This plugin exposes SO APIs that are used by the FTR client
instead of the public SO HTTP APIs. These APIs are configured to know
about all types, even hidden ones.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR upgrades uuid into its latest version `9.0.0`.
The previous default used version `v4` was kept where it was previously
used and places using `v1` or `v5` are still using it.
In this latest version they removed the deep import feature and as we
are not using tree shaking it increased our bundles by a significant
size. As such, I've moved this dependency into the `ui-shared-deps-npm`
bundle.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR implements a linter like the TS Project linter, except for
packages in the repo. It does this by extracting the reusable bits from
the TS Project linter and reusing them for the project linter. The only
rule that exists for packages right now is that the "name" in the
package.json file matches the "id" in Kibana.jsonc. The goal is to use a
rule to migrate kibana.json files on the future.
Additionally, a new rule for validating the indentation of tsconfig.json
files was added.
Validating and fixing violations is what has triggered review by so many
teams, but we plan to treat those review requests as notifications of
the changes and not as blockers for merging.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Dearest Reviewers 👋
I've been working on this branch with @mistic and @tylersmalley and
we're really confident in these changes. Additionally, this changes code
in nearly every package in the repo so we don't plan to wait for reviews
to get in before merging this. If you'd like to have a concern
addressed, please feel free to leave a review, but assuming that nobody
raises a blocker in the next 24 hours we plan to merge this EOD pacific
tomorrow, 12/22.
We'll be paying close attention to any issues this causes after merging
and work on getting those fixed ASAP. 🚀
---
The operations team is not confident that we'll have the time to achieve
what we originally set out to accomplish by moving to Bazel with the
time and resources we have available. We have also bought ourselves some
headroom with improvements to babel-register, optimizer caching, and
typescript project structure.
In order to make sure we deliver packages as quickly as possible (many
teams really want them), with a usable and familiar developer
experience, this PR removes Bazel for building packages in favor of
using the same JIT transpilation we use for plugins.
Additionally, packages now use `kbn_references` (again, just copying the
dx from plugins to packages).
Because of the complex relationships between packages/plugins and in
order to prepare ourselves for automatic dependency detection tools we
plan to use in the future, this PR also introduces a "TS Project Linter"
which will validate that every tsconfig.json file meets a few
requirements:
1. the chain of base config files extended by each config includes
`tsconfig.base.json` and not `tsconfig.json`
1. the `include` config is used, and not `files`
2. the `exclude` config includes `target/**/*`
3. the `outDir` compiler option is specified as `target/types`
1. none of these compiler options are specified: `declaration`,
`declarationMap`, `emitDeclarationOnly`, `skipLibCheck`, `target`,
`paths`
4. all references to other packages/plugins use their pkg id, ie:
```js
// valid
{
"kbn_references": ["@kbn/core"]
}
// not valid
{
"kbn_references": [{ "path": "../../../src/core/tsconfig.json" }]
}
```
5. only packages/plugins which are imported somewhere in the ts code are
listed in `kbn_references`
This linter is not only validating all of the tsconfig.json files, but
it also will fix these config files to deal with just about any
violation that can be produced. Just run `node scripts/ts_project_linter
--fix` locally to apply these fixes, or let CI take care of
automatically fixing things and pushing the changes to your PR.
> **Example:** [`64e93e5`
(#146212)](64e93e5806)
When I merged main into my PR it included a change which removed the
`@kbn/core-injected-metadata-browser` package. After resolving the
conflicts I missed a few tsconfig files which included references to the
now removed package. The TS Project Linter identified that these
references were removed from the code and pushed a change to the PR to
remove them from the tsconfig.json files.
## No bazel? Does that mean no packages??
Nope! We're still doing packages but we're pretty sure now that we won't
be using Bazel to accomplish the 'distributed caching' and 'change-based
tasks' portions of the packages project.
This PR actually makes packages much easier to work with and will be
followed up with the bundling benefits described by the original
packages RFC. Then we'll work on documentation and advocacy for using
packages for any and all new code.
We're pretty confident that implementing distributed caching and
change-based tasks will be necessary in the future, but because of
recent improvements in the repo we think we can live without them for
**at least** a year.
## Wait, there are still BUILD.bazel files in the repo
Yes, there are still three webpack bundles which are built by Bazel: the
`@kbn/ui-shared-deps-npm` DLL, `@kbn/ui-shared-deps-src` externals, and
the `@kbn/monaco` workers. These three webpack bundles are still created
during bootstrap and remotely cached using bazel. The next phase of this
project is to figure out how to get the package bundling features
described in the RFC with the current optimizer, and we expect these
bundles to go away then. Until then any package that is used in those
three bundles still needs to have a BUILD.bazel file so that they can be
referenced by the remaining webpack builds.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
After moving away from composite projects in the IDE we now have an
issue where projects like security solutions are getting `@types/jest`
and `@types/mocha` loaded up, even though the "types" compiler option in
security solutions focuses on jest. To fix this I've removed the
`@types/mocha` package, implemented/copied a portion of the mocha types
into a new `@kbn/ambient-ftr-types` package which can be used in ftr
packages to define the describe/it/etc. globals.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Removes all the noise from poorly written React tests and includes a
warning to explain the situation to folks
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Fixes https://github.com/elastic/kibana/issues/144051
Rather than just parsing process.argv with the default config of
getopts, which treats flags like `-u` into a "value collecting" flag,
this updates the way we call getopts so that all known jest CLI flags
are properly handled. This is accomplished by parsing the output of
`yarn jest --help` and then using that information to power `node
scripts/jest`.
To update the known CLI flags we just need to run `yarn jest --help |
node scripts/read_jest_help.mjs` (for some reason I don't understand,
Jest does not produce it's entire `--help` output when called from node,
only when called from a terminal).
In order to get us closer to the developer experience we want for
packages, we are trying to move package builds out of bazel and instead
we want to build files on demand. In the case of .peggy files this means
importing them directly and teaching babel/jest/webpack how to handle
these imports by automatically transpiling and caching the results.
This change does just that, adding a `@kbn/peggy` package which wraps
peggy for types, and also adds support for defining peggy config
adjacent to a peggy grammar file in a `${basename}.config.json` file.
This file will be parsed and used to configure things like
`allowedStartRules` as described in [the peggy
docs](https://peggyjs.org/documentation.html#generating-a-parser-javascript-api).
This PR also implements `@kbn/peggy-loader` which uses `@kbn/peggy` to
transpile peggy files in webpack, and a peggy transform for both Jest
and our custom babel register hook.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
https://jestjs.io/blog/2022/04/25/jest-28https://jestjs.io/blog/2022/08/25/jest-29
- jest.useFakeTimers('legacy') -> jest.useFakeTimers({ legacyFakeTimers:
true });
- jest.useFakeTimers('modern'); -> jest.useFakeTimers();
- tests can either use promises or callbacks, but not both
- test runner jasmine is no longer included, switch all suites to
jest-circus
Co-authored-by: Andrew Tate <andrew.tate@elastic.co>
The removed packages were empty becuase the packages for which they provide
types now ship with their own types. So they are no longer needed.
The following command was run to find them:
find node_modules/@types \
-mindepth 1 \
-maxdepth 1 \
-type d '!' \
-exec test -e "{}/index.d.ts" ';' \
-print
In this case that produced the following output:
node_modules/@types/moment-timezone
node_modules/@types/strip-ansi
node_modules/@types/joi
node_modules/@types/rrule
node_modules/@types/vfile-message
node_modules/@types/reduce-reducers
node_modules/@types/react-resize-detector
node_modules/@types/pretty-ms
Except for `vfile-message` all of these were direct dependencies and could be
removed.
* [ts] set allowJs to true by default
* fix scripts/check_ts_projects, original implementation is now wildly inefficient
* produce stats in check_ts_projects to make sure it's actually working
* fix imports
* fix flaky test 'produces a valid junit report for failures'
After the upgrading to Jest 27, it appears the runtime of this test is
occasionally reported as 0. 0 is evaluated to false and time is left
out of the junit report. This updates the conditional to check for type
number.
Closes#143993
* unskip
* un-skip tests in endpoint_responder
* move endpoint responder tests to integration tests
* [CI] Auto-commit changed files from 'node scripts/precommit_hook.js --ref HEAD~1..HEAD --fix'
* Add jest integration config file
* add standard setup for react testing `data-test-subj` testIdAttribute
* change `@kbn/test/jest_integration` preset to include all `setupFilesAfterEnv` from base preset
* Fix jest testing warning/error about missing react `key` in command_usage.tsx component
* Stabilise test when checking calls to action details api
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
* [ftr] add first-class support for playwrite journeys
* [CI] Auto-commit changed files from 'node scripts/generate codeowners'
* fix jest test
* remove ability to customize kibana server args, if we need it we can add it back
* remove dev dir that doesn't exist
* fix typo
* prevent duplicated array converstion logic by sharing flag reader
* remove destructuring of option
* fix scalability config and config_path import
* fix start_servers args and tests
* include simple readme
* fix jest tests and support build re-use when changes are just to jest tests
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
* tty toggle now shows number of bytes in tooltip, if no output we disable button (instead of hide)
* fixed tests
Co-authored-by: Karl Godard <karlgodard@elastic.co>
* [packages] add kibana.jsonc files
* auto-migrate to kibana.jsonc
* support interactive pkg id selection too
* remove old codeowners entry
* skip codeowners generation when .github/CODEOWNERS doesn't exist
* fall back to format validation if user is offline
* update question style
* [CI] Auto-commit changed files from 'node scripts/eslint --no-cache --fix'
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
* deletes unused utils file
* just some fix while I see it
* creating empty packages
* moving all the things
* package build success
* start fixing usages
* fix the scoped history type issue
* export internal utils
* add default for mock
* fix test import
* fix external import
* start fixing external usages
* more usages
* more usages
* more usages
* More usages
* [CI] Auto-commit changed files from 'node scripts/precommit_hook.js --ref HEAD~1..HEAD --fix'
* fix integration test imports
* fix more test types
* remove public/utils from the core bundle
* trying to import from the package
* updating README's
* remove unused test types from mock package
* cleanup test types
* use import type
* add author to packages
* more import type
* remove dead path from some config
* remove src/core/utils/index.ts (and pray)
* update tsdoc
* fix new file usage
* fix paths
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
