# Backport
This will backport the following commits from `main` to `8.13`:
- [[kbn-test] remove deprecated auth route
(#179561)](https://github.com/elastic/kibana/pull/179561)
<!--- Backport version: 9.4.3 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Dzmitry
Lemechko","email":"dzmitry.lemechko@elastic.co"},"sourceCommit":{"committedDate":"2024-04-03T11:59:40Z","message":"[kbn-test]
remove deprecated auth route (#179561)\n\n## Summary\r\n\r\nSince ms-104
was released, we no longer need to support both deprecated\r\nand new
cloud auth route.\r\n\r\nHow to test: run any FTR test with SAML auth
against MKI
project","sha":"e832852938a08cd95ad9e760a79a0184fcf23fea","branchLabelMapping":{"^v8.14.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","FTR","v8.14.0","v8.13.1"],"title":"[kbn-test]
remove deprecated auth
route","number":179561,"url":"https://github.com/elastic/kibana/pull/179561","mergeCommit":{"message":"[kbn-test]
remove deprecated auth route (#179561)\n\n## Summary\r\n\r\nSince ms-104
was released, we no longer need to support both deprecated\r\nand new
cloud auth route.\r\n\r\nHow to test: run any FTR test with SAML auth
against MKI
project","sha":"e832852938a08cd95ad9e760a79a0184fcf23fea"}},"sourceBranch":"main","suggestedTargetBranches":["8.13"],"targetPullRequestStates":[{"branch":"main","label":"v8.14.0","branchLabelMappingKey":"^v8.14.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/179561","number":179561,"mergeCommit":{"message":"[kbn-test]
remove deprecated auth route (#179561)\n\n## Summary\r\n\r\nSince ms-104
was released, we no longer need to support both deprecated\r\nand new
cloud auth route.\r\n\r\nHow to test: run any FTR test with SAML auth
against MKI
project","sha":"e832852938a08cd95ad9e760a79a0184fcf23fea"}},{"branch":"8.13","label":"v8.13.1","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
## Summary
This PR refactors `run_performance` script logic that we use to run
single user performance journeys:
- simplify script by keeping only 2 functions: `startES` &
`runFunctionalTest`
- write ES and Kibana logs (for warmup phase) to files instead of
console output;
- upload files with server log as build artifacts
- do not retry journey TEST phase run on failure, it doubles EBT metrics
and does not provide much value: journey should be simple and stable.
- do not retry step running journeys, most of the failures are due to
journey flakiness and we just skip them
Testing performance pipeline
https://buildkite.com/elastic/kibana-single-user-performance/builds/12552
Before:
<img width="1243" alt="image"
src="c4635986-6552-4842-abf9-640f09630674">
After
<img width="1243" alt="Screenshot 2024-02-02 at 13 56 23"
src="47ff6a76-d8dd-44dd-93a5-2c49ef87e808">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
in https://github.com/elastic/kibana/pull/174284 we split serverless
roles into individual files per project.
If you run `yarn es serverless --ssl` ES will be provisioned only with
roles specified for elastisearch project type.
To use roles for oblt/security projects, you have to override roles file
with `--resources` flag:
```
yarn es serverless --ssl --resources /Users/dmle/github/kibana/packages/kbn-es/src/serverless_resources/project_roles/security/roles.yml
```
Since it is confusing and not dev-friendly approach, this PR adds new
required flag to `serverless` script: `--projectType`
Usage:
`yarn es serverless --projectType=es --ssl`
`yarn es --serverless=oblt --ssl`
roles.yml file will be picked up based on `projectType` value, you still
have an option to override it using `--resources` flag
How to test:
`yarn es serverless --project-type=oblt --ssl`
`yarn start serverless=oblt --ssl`
You should be able to login with all roles defined or Observability (and
other) project.
Cli docs were updated:
```
[main][~/github/kibana]$ node scripts/es --help
usage: es <command> [<args>]
Assists with running Elasticsearch for Kibana development
Available commands:
snapshot - Downloads and run from a nightly snapshot
source - Build and run from source
archive - Install and run from an Elasticsearch tar
build_snapshots - Build and collect ES snapshots
docker - Run an Elasticsearch Docker image
serverless - Run Serverless Elasticsearch through Docker
To start a serverless instance use the 'serverless' command with
'--projectType' flag or use the '--serverless=<ProjectType>'
shortcut, for example:
es --serverless=es
Global options:
--help
```
---------
Co-authored-by: Robert Oskamp <traeluki@gmail.com>
## Summary
We see quite frequently this kind of error in Jest unit tests:
```
Error: The `document` global was defined when React was initialized, but is not defined anymore. This can happen in a test environment if a component schedules an update from an asynchronous callback, but the test has already finished running. To solve this, you can either unmount the component at the end of your test (and ensure that any asynchronous operations get canceled in `componentWillUnmount`), or you can change the test itself to be asynchronous.
```
As the test execution stops due to this runtime error, and the console
logging is disabled in CI, we don't see a lot of the context of the
error.
This PR adds minimal extra logging when the case of this error happens.
## Summary
in #174284 we split serverless roles into individual files per project.
This PR updates mock-idp-plugin we use to simulate SAML auth in "local"
setup to fetch roles based on `projectType` from the respective yml
file:
- since we read roles from a yml file, new end point `GET
/mock_idp/supported_roles` was added to handle it.
- loginPage & rolesSwitcher hooks are updated to fetch roles via http
- hardcoded roles removed
Few other changes were made:
- move `readRolesFromResource` from `kbn-test` to `kbn-es` for
convenience: it is used to read ES resource files.
- move `system_indices_superuser` to the bottom of the file so it won't
be the first choice in UI role selector (+ we plan to remove the value
in the future)
- Change MOCK_IDP_REALM_NAME to `cloud-saml-kibana` as it is the actual
provider name we use in setup.
<img width="1026" alt="image"
src="060b3c21-9c1a-4210-8b5f-2d574a8f78e7">
<img width="1593" alt="image"
src="4afde9df-5a7e-4ae5-a9f5-ab18b871fc1b">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR adds the ResizeObserver polyfill in Jest Tests reusing a
polyfill already used in Kibana.
The PR also removes all the mocks for the ResizeObserver used in tests.
The polyfill is no longer needed in code running on a browser as the
[ResizeObserver API is already
available](https://developer.mozilla.org/en-US/docs/Web/API/ResizeObserver#browser_compatibility)
in every Kibana-supported browser.
There is still one last polyfill to remove `@juggle/resize-observer` but
this is used internally by the `use-resize-observer` hook. A following
PR could probably replace that hook with a different hook that doesn't
require that polyfill to cleanup a bit our dependencies
## Summary
To make local/CI testing env closer to MKI experience this PR updates
serverless roles for each project to be defined in its own yml file.
When FTR tests are run, only project specific roles defined in the file
are provisioned. I use `kbnTestServer.serverArgs` from FTR config to get
projectType from `--serverless=<projectType>` and pass it to `kbn-es`.
If you start ES using `es serverless [<args>]` it will provision roles
defined for 'es' project by default, you need to use `--resources` flag
to override it with roles for other project types.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Recently the cloud api we use for saml auth in our FTR tests was removed
in [cloud#123010](https://github.com/elastic/cloud/pull/123010)
Since this change is still not released to all environments, this PR
adds temporary support for both endpoints.
It also changes the way of getting user full name by making API call to
kibana server
## Summary
This PR adds a script that determines GitHub code ownership for
functional test files in the Kibana repository.
### Why do we need this?
We want to be able to determine test ownership to allow teams to get a
better overview of their tests (number of tests, number of skipped
tests, number of failures in the last x days, etc).
### What does this PR bring?
This PR is a first step on closing the test ownership gaps. It adds
functionality to determine the GitHub code owner for a given file (in
the `@kbn/code-owners` package) and adds a script that makes use of this
to check if all functional test files have a code owner, reporting the
gaps.
### Future plans
The idea is to include the test ownership information in our ingested
test results, such that we can create dashboards, reports, etc based on
it.
At some point (once all ownership gaps are closed), we might consider
running this check on CI to prevent new test files without owners.
### How to run?
```
node scripts/check_ftr_code_owners.js
```
The script lists the functional test files that are not covered by code
owners and also gives a summary like this:
```
ERROR Found 2592 test files without code owner (checked 7550 test files in 12.73 s)
```
## Summary
This PR moves SAML session creation from FTR service to `@kbn/test`. It
should simplify its adoption in non-FTR context, e.g. Cypress tests or
jest integration tests:
```
import { SamlSessionManager } from '@kbn/test';
// create instance in your setup file
const sessionManager = new SamlSessionManager({
hostOptions: {
protocol,
hostname,
port,
username,
password,
},
log,
isCloud
});
```
use it in your tests
```
sessionManager.getSessionCookieForRole('viewer');
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.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) |
[`^4.1.0` ->
`^4.2.0`](https://renovatebot.com/diffs/npm/elastic-apm-node/4.1.0/4.2.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 (elastic-apm-node)</summary>
###
[`v4.2.0`](https://togithub.com/elastic/apm-agent-nodejs/releases/tag/v4.2.0)
[Compare
Source](https://togithub.com/elastic/apm-agent-nodejs/compare/v4.1.0...v4.2.0)
For more information, please see the
[changelog](https://www.elastic.co/guide/en/apm/agent/nodejs/current/release-notes-4.x.html#release-notes-4.2.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-4-2-0:1|
|ap-east-1|arn:aws:lambda:ap-east-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|ap-northeast-1|arn:aws:lambda:ap-northeast-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|ap-northeast-2|arn:aws:lambda:ap-northeast-2:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|ap-northeast-3|arn:aws:lambda:ap-northeast-3:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|ap-south-1|arn:aws:lambda:ap-south-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|ap-southeast-1|arn:aws:lambda:ap-southeast-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|ap-southeast-2|arn:aws:lambda:ap-southeast-2:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|ap-southeast-3|arn:aws:lambda:ap-southeast-3:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|ca-central-1|arn:aws:lambda:ca-central-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|eu-central-1|arn:aws:lambda:eu-central-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|eu-north-1|arn:aws:lambda:eu-north-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|eu-south-1|arn:aws:lambda:eu-south-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|eu-west-1|arn:aws:lambda:eu-west-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|eu-west-2|arn:aws:lambda:eu-west-2:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|eu-west-3|arn:aws:lambda:eu-west-3:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|me-south-1|arn:aws:lambda:me-south-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|sa-east-1|arn:aws:lambda:sa-east-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|us-east-1|arn:aws:lambda:us-east-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|us-east-2|arn:aws:lambda:us-east-2:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|us-west-1|arn:aws:lambda:us-west-1:267093732750:layer:elastic-apm-node-ver-4-2-0:1|
|us-west-2|arn:aws:lambda:us-west-2:267093732750:layer:elastic-apm-node-ver-4-2-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:eyJjcmVhdGVkSW5WZXIiOiIzNy41OS44IiwidXBkYXRlZEluVmVyIjoiMzcuNTkuOCIsInRhcmdldEJyYW5jaCI6Im1haW4ifQ==-->
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: pgayvallet <pierre.gayvallet@elastic.co>
## Summary
This PR disables TLS mode for Kibana run in serverless.
Related to #170417 enabling serverless roles testing
Blocked by #171513
PR is created in cooperation with @azasypkin and intended to simplify
the automated testing process for serverless:
starting Kibana with TLS enabled adds unnecessary complexity to the
process of getting session cookie and overall Kibana APIs calling with
Dev certificate in the tests.
The selected approach is to disable TLS for Kibana and simply rely on
#171513 to configure mocked idp realm for Serverless ES with TLS
enabled.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Goal of this PR is to re-enable the serverless tests that require the
login credentials for users that have the pre-defined roles from
serverless assigned to them.
### `@kbn/test` changes
- Added support for `esServerlessOptions` to FTR config. Currently
allows for `resources` to be defined
- `resources` overrides were introduced [in this
PR](https://github.com/elastic/kibana/pull/167087)
- new FTR option will allow for testing serverless with a set of
users/roles that are specific to the project type
### Security Solution Plugin
- Added `esServerlessOptions` to the Defend Workflows cypress
configurations
- Un-skips all serverless specific tests (now that we have support for
users/roles that are specific to the Security project)
- Changed the default username for cypress `login()` task to be
`endpoint_operations_analyst`
- Note that the previously used `endpoint_operations_analyst` role was
also updated to match the definition used for serverless.
- Added new common `fleet_server_services` cli module with reusable
methods for working with fleet server, including generic
`startFleetServer()` method
- New CLI script: `node
x-pack/plugins/security_solution/scripts/endpoint/start_fleet_server.js`
- Starts a fleet server locally (via Docker) and connects it to the
Kibana
- Supports running fleet server locally for serverless as well
## Summary
This PR wraps up the work the @elastic/kibana-presentation team has done
to finish the MVP of [Phase
1](https://github.com/elastic/kibana/issues/154354) of the `Link`
embeddable, which enables users to add panels to their dashboard that
contain links to other dashboards + external links - with respect to
dashboard links, we give the author control over which pieces of context
should be kept across dashboards so that things like filter pills,
queries, and time ranges are not lost. This marks a huge improvement in
dashboard navigation overall, which was previously only available via a
variety of different workarounds including (but not limited to):
- Creating (essentially) a `noop` dashboard-to-dashboard drilldown
- Using markdown panels with hard Dashboard links, which are prone to
break across updates
- Avoiding navigation all together, which resulted in large,
slow-to-load dashboards.
As an added benefit, because these panels contain **references** to each
dashboard rather than hard links, (1) unlike markdown links, they should
not break after updates and (2) if a links panel is exported and
imported into another space or instance, all of the dashboards it links
to will also be imported.
1a86b713-47e7-4db9-8a04-29d41b13681a
> **Note**
> 🔉 The above video has audio! Turn on your sound for the best
experience.
### Note about this PR
- A majority of this work was done on a feature branch, with thorough
reviews from @andreadelrio on behalf of @elastic/kibana-design along the
way. Therefore, while feedback on the design is encouraged, any large
concerns brought up in this PR should be filed as separate issues and
addressed in follow-up PRs.
- This PR contains work for giving embeddables control over their own
panel size / default positioning on the dashboard. This was especially
important for the links panel, since we assume that (a) most links
panels would be located somewhere near the top of the dashboard and (b)
the horizontal links panel should have a different default "shape"
(longer than it is tall) than the vertical panel (taller than it is
long).
- This PR also contains work for caching dashboard saved objects, which
makes navigation much more seamless.
### Flaky Test Runner
-
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/3251
### Checklist
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [ ]
~[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials~ This will
be addressed in a follow up:
https://github.com/elastic/kibana/issues/166750
- [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 - ~Units tests
are added, functional tests are forthcoming~ Edit: All tests are in.
- [x] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [x] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [x] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [x] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### 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: Nick Peihl <nick.peihl@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Andrea Del Rio <delrio.andre@gmail.com>
Co-authored-by: Devon Thomson <devon.thomson@elastic.co>
Co-authored-by: Nick Peihl <nickpeihl@gmail.com>
Co-authored-by: Gerard Soldevila <gerard.soldevila@elastic.co>
## Summary
Prepares the serverless FTR tests to be runnable with a custom ES image.
(`--esServerlessImage` cli arg)
Creates a pipeline for testing and promoting ES Serverless docker
releases.
The job can be triggered here:
https://buildkite.com/elastic/kibana-elasticsearch-serverless-verify-and-promote
The three main env variables it takes:
- BUILDKITE_BRANCH: the kibana branch to test with (maybe not as
important)
- BUILDKITE_COMMIT: the kibana commit to test with
- ES_SERVERLESS_IMAGE: the elasticsearch serverless image, or tag to use
from this repo:
`docker.elastic.co/elasticsearch-ci/elasticsearch-serverless`
## TODOS:
- [x] set `latest_verified` with full img path as default
- [x] ~~find other CLIs that might need the `esServerlessImage` argument
(if the docker runner has multiple usages)~~ | I confused the `yarn es
docker` with this, because I thought we only run ES serverless in a
docker container, but `elasticsearch` can also be run in docker.
- [x] set `latest-compatible` or similar flag in a manifest in gcs for
Elastic's use-case
- [ ] ensure we can only verify "forward" (ie.: to avoid a
parameterization on old versions to set our pointers back) [on a second
thought, this might be kept as a feature to roll back (if we should ever
need that)]
There are two confusing things I couldn't sort out just yet:
#### Ambiguity in --esServerlessImage
We can either have 2 CLI args: one for an image tag, one for an image
repo/image url, or we can have one (like I have it now) and interpret
that in the code, it can be either the image url, or the tag. It's more
flexible, but it's two things in one. Is it ok this way, or is it too
confusing?
e.g.:
```
node scripts/functional_tests --esFrom serverless --esServerlessImage docker.elastic.co/elasticsearch-ci/elasticsearch-serverless:git-8fc8f941bd4d --bail --config x-pack/test_serverless/functional/test_suites/security/config.ts
# or
node scripts/functional_tests --esFrom serverless --esServerlessImage latest --bail --config x-pack/test_serverless/functional/test_suites/security/config.ts
```
#### Ambiguity in the default image path
The published ES Serverless images will sit on this image path:
`docker.elastic.co/elasticsearch-ci/elasticsearch-serverless`, however,
our one exception is the `latest-verified` which we will be tagging
under a different path, where we have write rights:
`docker.elastic.co/kibana-ci/elasticsearch-serverless:latest-verified`.
Is it okay, that by default, we're searching in the `elasticsearch-ci`
images for any tags as parameters (after all, all the new images will be
published there), however our grand default will ultimately be
`docker.elastic.co/kibana-ci/elasticsearch-serverless:latest-verified`.
## Links
Buildkite:
https://buildkite.com/elastic/kibana-elasticsearch-serverless-verify-and-promote
eg.:
https://buildkite.com/elastic/kibana-elasticsearch-serverless-verify-and-promote/builds/24
Closes: https://github.com/elastic/kibana/issues/162931
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes#166543
- It is counterintuitive to `CTRL + C` from the `yarn es serverless`
process and the cluster is still running. This has caused issues when
switching between stateful and serverless work flows for some
developers. This PR inverts the logic to always teardown the cluster
unless a flag is passed.
- Small docs update for changing ES memory allocation on all operation
systems.
- Fixes bug were cluster status would continue looping after `SIGINT`.
- Bind to `SIGINT` earlier so nodes are always killed
## Summary
Upgrade `openpgp` from `5.3.0` to `5.10.1`
Commit log:
https://github.com/openpgpjs/openpgpjs/compare/v5.3.0...v5.10.1
There is an incompatibility of `Uint8Array` when using Jest/JSDom with
the TextEncoder/TextDecoder from node `util`.
`https://github.com/kayahr/text-encoding` has been added as a
`devDependency` so it can be used in the polyfill. It provides a working
TextEncoder/Decoder for our Jest tests.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/161876
Creates a plugin providing utilities to access metrics data. The plugin
only exposes a server API which includes a client with two methods:
- `getMetricIndices` to retrieve the user-defined indices where metrics
are located
- `updateMetricIndices` to update the indices
The client is now used where we previously relied on infra plugin to
provide the configuration, in APM and Infra.
The plugin persists the configuration in a new saved object
`metrics-data-source`. Because this configuration was previously stored
in the `infrastructure-ui-source`, the plugin relies on a fallback to
reuse any existing value (see additional context
https://github.com/elastic/kibana/issues/161876#issuecomment-1673537400).
### Reviewers
There are no functional changes outside of Infra Monitoring UI and APM
UI, other codeowners are involved because this introduces a new saved
object
- APM - the change introduces a drop-in replacement of the
`infra.getMetricIndices` call. The ui code still relies on infra plugin
for a couple of components so we can't drop the dependency yet, those
we'll need to be moved to a tier 2 plugin (more details in
https://github.com/elastic/observability-dev/discussions/2787
(internal)) in a separate issue
### Testing
You'll need metrics data to verify data fetching works (I've used an
edge-oblt cluster)
1. Navigate to Infrastructure Settings and verify metric indices are
configured with the default value of `infrastructure-ui-source`
2. Update metric indices settings (if connected to oblt cluster add
`remote_cluster:..` indices)
3. Verify `metrics-data-source` saved object is persisted with correct
attributes
4. Verify Infrastructure Inventory is pulling data from the newly
configured indices
5. Go to APM services, verify service Infrastructure pulls data from
newly configured indices
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Jason Rhodes <jason.rhodes@elastic.co>
## Summary
Converting cluster.js to typescript with small logic adjustment. It
should improve readability and simplify maintenance:
keep the following cluster properties solely for stateful
source/snapshot ES instance:
- process
- outcome
- setupPromise
- stdioTarget
Use `serverlessNodes` prop to check if serverless ES was started in
`runServerless/stop/kill`
Remove return statement for `runDocker` & `runDockerContainer` as the
result (e.g. pid) is not used anyways, but assigning to `process` prop
lead to confusion (more in comments)
Adding more tests to increase cluster functionality coverage.
## Summary
Due to most users needing security plugin enabled by default, this
adjusts to that. Which requires transport SSL to be enabled as well. The
`--ssl` flag now will enable HTTP SSL only.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Closes#162593Closes#163939Closes#162625
The original intention of this PR was to add FTR support for ESS.
However the scope increased as that also required adding SSL support due
to tests failing from disabled `security` and no authentication.
Additionally, after using serverless in `kbn/es` extensively for this,
there was a bit of friction in regards to DX.
## Summary
- Switch `x-pack/test_serverless` FTR to use ES serverless instead of
(stateful) snapshot
- Adds SSL support to Docker and Serverless in `kbn/es`
- Adds `port` option override
- Adds `teardown` option to kill running nodes if the process exits
without shutdown
- Adds `kill` option to kill running nodes on startup if detected
- Adds `--esFrom serverless` to FTR CLI
- Adds `files` option to mount extra files into containers
- For serverless, automatically attach to first node with `docker logs
-f es01` on startup for better DX.
- Added `background` flag to not attach `logs`.
- Adds graceful shutdown for ESS cluster
- Separate `docker pull` from `run` for better logging, ensures latest
image and stops multiple pulls of the same image occurring in parallel
- Align (most) default settings for ES serverless with `gradlew`
[settings](https://github.com/elastic/elasticsearch-serverless/blob/main/serverless-build-tools/src/main/kotlin/elasticsearch.serverless-run.gradle.kts#L8)
- Fixes Docker bind mount permissions in CI
- Fixes issue where `esFrom` would default to `snapshot` and override
FTR config settings.
### 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
## Related Issues for Skipped Tests
Security Threat Hunting: #165135
Observability: #165138
Response Ops: #165145
---------
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
Co-authored-by: Tiago Costa <tiago.costa@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Patryk Kopycinski <contact@patrykkopycinski.com>
## [Security Solution] [Elastic AI Assistant] LangChain integration (experimental)
This PR integrates [LangChain](https://www.langchain.com/) with the [Elastic AI Assistant](https://www.elastic.co/blog/introducing-elastic-ai-assistant) as an experimental, alternative execution path.
### How it works
- There are virtually no client side changes to the assistant, apart from a new branch in `x-pack/packages/kbn-elastic-assistant/impl/assistant/api.tsx` that chooses a path based on the value of the `assistantLangChain` flag:
```typescript
const path = assistantLangChain
? `/internal/elastic_assistant/actions/connector/${apiConfig?.connectorId}/_execute`
: `/api/actions/connector/${apiConfig?.connectorId}/_execute`;
```
Execution of the LangChain chain happens server-side. The new route still executes the request via the `connectorId` in the route, but the connector won't execute the request exactly as it was sent by the client. Instead, the connector will execute one (or more) prompts that are generated by LangChain.
Requests routed to `/internal/elastic_assistant/actions/connector/${apiConfig?.connectorId}/_execute` will be processed by a new Kibana plugin located in:
```
x-pack/plugins/elastic_assistant
```
- Requests are processed in the `postActionsConnectorExecuteRoute` handler in `x-pack/plugins/elastic_assistant/server/routes/post_actions_connector_execute.ts`.
The `postActionsConnectorExecuteRoute` route handler:
1. Extracts the chat messages sent by the assistant
2. Converts the extracted messages to the format expected by LangChain
3. Passes the converted messages to `executeCustomLlmChain`
- The `executeCustomLlmChain` function in `x-pack/plugins/elastic_assistant/server/lib/langchain/execute_custom_llm_chain/index.ts`:
1. Splits the messages into `pastMessages` and `latestMessage`, where the latter contains only the last message sent by the user
2. Wraps the conversation history in the `BufferMemory` LangChain abstraction
3. Executes the chain, kicking it off with `latestMessage`
```typescript
const llm = new ActionsClientLlm({ actions, connectorId, request });
const pastMessages = langchainMessages.slice(0, -1); // all but the last message
const latestMessage = langchainMessages.slice(-1); // the last message
const memory = new BufferMemory({
chatHistory: new ChatMessageHistory(pastMessages),
});
const chain = new ConversationChain({ llm, memory });
await chain.call({ input: latestMessage[0].content }); // kick off the chain with the last message
};
```
- When LangChain executes the chain, it will invoke `ActionsClientLlm`'s `_call` function in `x-pack/plugins/elastic_assistant/server/lib/langchain/llm/actions_client_llm.ts` one or more times.
The `_call` function's signature is defined by LangChain:
```
async _call(prompt: string): Promise<string>
```
- The contents of `prompt` are completely determined by LangChain.
- The string returned by the promise is the "answer" from the LLM
The `ActionsClientLlm` extends LangChain's LLM interface:
```typescript
export class ActionsClientLlm extends LLM
```
This let's us do additional "work" in the `_call` function:
1. Create a new assistant message using the contents of the `prompt` (`string`) argument to `_call`
2. Create a request body in the format expected by the connector
3. Create an actions client from the authenticated request context
4. Execute the actions client with the request body
5. Save the raw response from the connector, because that's what the assistant expects
6. Return the result as a plain string, as per the contact of `_call`
## Desk testing
This experimental LangChain integration may NOT be enabled via a feature flag (yet).
Set
```typescript
assistantLangChain={true}
```
in `x-pack/plugins/security_solution/public/app/app.tsx` to enable this experimental feature in development environments.
## Summary
upgrade `axios` to 1.4
- adjust to header usage, and config optionality
- Axios' adapters are now resolved from a string key by axios, no need
to import/instantiate adapters
- most of the changed code stems from changes in Axios' types
- `response.config` is now optional
- there was a change in the type of AxiosHeaders <->
InternalAxiosHeaders
Closes: #162661Closes: #162414
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## 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
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
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>
