## Summary
After https://github.com/elastic/kibana/pull/214843, `axios` client
usages need to set a flag to prevent the vulnerable behavior.
To reviewers: if you think it's a mistake, and you created a client to
request for absolute URLs, consider unsetting the `baseURL` to
communicate intent.
## Summary
After upgrading the ES client to 9.0
(https://github.com/elastic/kibana/pull/208776), we noticed that the CI
fails to upload the results of the tests to the CI cluster:
```
ERROR ResponseError: media_type_header_exception
Caused by:
status_exception: Accept version must be either version 8 or 7, but found 9. Accept=application/vnd.elasticsearch+json; compatible-with=9
Root causes:
media_type_header_exception: Invalid media-type value on headers [Content-Type, Accept]
```
This PR makes sure that the CI client is still using v8.x until we
upgrade that cluster.
## Summary
Updating the ES client to 9.0.
Resolves#116102
## What changes?
**Breaking change**: `body` has been removed.
Most of the changes are about bringing all the content inside the body
as a root attribute to the API params:
```diff
const response = await client.search({
index: 'test',
- body: {
query: {
match_all: {}
}
- }
})
```
For this reason, enabling the "Hide whitespace changes" option when
reviewing is recommended.
Some exceptions to this rule:
* Bulk APIs replace the `body` array with `operations` array (direct
replacement)
* Index Put Settings API replace `body` array with `settings` (direct
replacement)
* Msearch replaces the `body` array with `searches` array (direct
replacement)
* Document Index API replaces `body` with `document` (direct
replacement)
* Create Repository replaces `body` with `repository` (direct
replacement)
Because of a known issue in the client
(https://github.com/elastic/elasticsearch-js/issues/2584), there's still
an escape hatch to send data in the body in case the specific use case
requires it via `// @ts-expect-error elasticsearch@9.0.0
https://github.com/elastic/elasticsearch-js/issues/2584`, but it
shouldn't be abused because we lose types. In this PR we've used it in
those scenarios where we reuse the response of a GET as the body of a
PUT/POST.
### Other changes
* `estypes` can be imported from the root of the library as `import type
{ estypes } from '@elastic/elasticsearch';`
* `estypesWithBody` have been removed
* `requestTimeout`'s 30s default has been removed in the client. This PR
explicitly adds the setting in all client usages.
### Identify risks
- [x] The client places unknown properties as querystring, risking body
params leaking there, and causing 400 errors from ES => Solved by
forcing `body` usage there via `// @ts-expect-error elasticsearch@9.0.0
https://github.com/elastic/elasticsearch-js/issues/2584`. The next
version of the client will address this.
- [x] We need to run the MKI tests to make sure that we're not breaking
anything there =>
https://elastic.slack.com/archives/C04HT4P1YS3/p1739528112482629?thread_ts=1739480136.231439&cid=C04HT4P1YS3
---------
Co-authored-by: Gloria Hornero <gloria.hornero@elastic.co>
## Summary
The `/packages` folder at the root of the Kibana repository used to
contain a lot of packages.
In the context of SKA, they have been gradually moved to various
locations:
* `src/platform/packages`
* `x-pack/platform/packages`
* `src/core/packages`
Currently, only `devOnly: true` packages are left in this folder. This
comprises libraries for CLI scripts as well as testing utilities.
With this PR, we are moving ~half of these packages under
`src/platform/packages/(private|shared)/`.
In particular, we are moving those packages that are being used from
platform and/or solutions.
Since they are `"devOnly": true`, this means they are ONLY used from
tests, cypress tests, storybook configs, ./scripts/ folders inside some
modules, or other non-prod-time logic. Nonetheless, they are effectively
referenced from platform and/or solutions code, hence I decided they
should be placed under `platform` folders.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Extending scout-reporter with `failed-test-reporter`, that saves
failures in json summary file. For each test failure html report file is
generated and linked in summary report:
```
[
{
"name": "stateful - Discover app - saved searches - should customize time range on dashboards",
"htmlReportFilename": "c51fcf067a95b48e2bbf6098a90ab14.html"
},
{
"name": "stateful - Discover app - value suggestions: useTimeRange enabled - dont show up if outside of range",
"htmlReportFilename": "9622dcc1ac732f30e82ad6d20d7eeaa.html"
}
]
```
This PR updates `failed_tests_reporter_cli` to look for potential Scout
test failures and re-generate test failure artifacts in the same format
we already use for FTR ones.
These new artifacts are used to list failures in BK annotation:
<img width="1092" alt="image"
src="https://github.com/user-attachments/assets/09464c55-cdaa-45a4-ab47-c5f0375b701c"
/>
test failure html report example:
<img width="1072" alt="image"
src="https://github.com/user-attachments/assets/81f6e475-1435-445d-82eb-ecf5253c42d3"
/>
Note for reviewer: 3 Scout + 1 FTR tests were "broken" to show/test
reporter, those changes must be reverted before merge. See failed
pipeline
[here](https://buildkite.com/elastic/kibana-pull-request/builds/266822)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Resolves: https://github.com/elastic/kibana/issues/202687
### For Reviewers
#### To test locally, make a test fail, something like
```
diff --git a/test/functional/apps/console/_autocomplete.ts b/test/functional/apps/console/_autocomplete.ts
index 0e29b29e96e..78976e6d54b 100644
--- a/test/functional/apps/console/_autocomplete.ts
+++ b/test/functional/apps/console/_autocomplete.ts
@@ -50,14 +50,14 @@ export default function ({ getService, getPageObjects }: FtrProviderContext) {
await PageObjects.console.setAutocompleteTrace(false);
});
- it('should provide basic auto-complete functionality', async () => {
+ it.only('should provide basic auto-complete functionality', async () => {
await PageObjects.console.enterText(`GET _search\n`);
await PageObjects.console.pressEnter();
await PageObjects.console.enterText(`{\n\t"query": {`);
await PageObjects.console.pressEnter();
await PageObjects.console.sleepForDebouncePeriod();
await PageObjects.console.promptAutocomplete();
- expect(PageObjects.console.isAutocompleteVisible()).to.be.eql(true);
+ expect(false).to.be.eql(true);
});
it('should not show duplicate suggestions', async () => {
```
#### Then run the tests:
`TEST_BROWSER_HEADLESS=1 CI=1 node scripts/functional_tests
--config=test/functional/apps/console/config.ts --bail`
#### Then run the reporter to see the html file
`JOB_NAME=elastic+kibana+7.x node scripts/report_failed_tests
--build-url="${BUILDKITE_BUILD_URL}#${BUILDKITE_JOB_ID}"
'target/junit/**/*.xml' --no-github-update --no-index-errors`
#### Lastly, inspect the HTML File
`grep elastic target/test_failures/*.html -B 2`
```
<div>
<strong>Owners</strong>:
<pre>elastic/kibana-management</pre>
--
</div>
<div>
<a href="https://github.com/elastic/kibana/issues/156926">https://github.com/elastic/kibana/issues/156926</a>
--
<h5>Stdout</h5>
<pre>Failed Tests Reporter:
- Test has failed 1 times on tracked branches: https://github.com/elastic/kibana/issues/156926
Failed Tests Reporter:
- Test has failed 1 times on tracked branches: https://github.com/elastic/kibana/issues/156926
Failed Tests Reporter:
- Test has failed 1 times on tracked branches: https://github.com/elastic/kibana/issues/156926
```
Notice the `<pre>elastic/kibana-management</pre>` in the output of grep
Also, you can continue verification of the ownership value, via: `node
scripts/get_owners_for_file.js --file
test/functional/apps/console/_autocomplete.ts`
```
succ Found matching entry in .github/CODEOWNERS:
test/functional/apps/console/*.ts elastic/kibana-management
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR is accompanied with the [PR in kibana-operations
repo](https://github.com/elastic/kibana-operations/pull/236) and
integrates the security solution quality gate pipelines with the
functionality to create ticket when a test fails and then notify the
respective **codeowner** team with a _Test failed alert_. Also when a
test fails a second time and a ticket exist a new comment is added in
the same issue that the test failed again in a given pipeline.
Last a similar flow exist when a test is skipped by a team.
**Specifications:**
- In the `failed_test_reporter_cli.ts` [a new field is introduced
](https://github.com/elastic/kibana/compare/main...security-mki-github-tickets#diff-bb801c18fd2e1a3a36a3b39fbf02c1abe337c46c201ad5a01239a9d2501d4b56R47)`prependTitle`
which is initialized by the environmental variable
`process.env.PREPEND_FAILURE_TITLE` if exists, in order to add a custom
text of preference before the issue title.
The scope of this is to be able to give the team the opportunity to add
some tags or any convention agreed within the team in the issue created
in order to easily understand the context without opening the ticket. If
this field is not initialized, the normal existing flow proceeds.
[Here](https://github.com/elastic/kibana/issues/197133) an example of
the prependTitle usage can be seen where the tags `[MKI][QA]` are
prepended in order to identify where did the test fail, having the same
exactly tests running on both CI and MKI. This means that a github issue
with the exact same title would be created for both cases if this
prepend title field would not exist.
- In the
[junit_transformer/lib.ts](https://github.com/elastic/kibana/compare/main...security-mki-github-tickets#diff-31c5651af613c7d02139f3e9fccd00ddb997f2502523372dd19db9e0659a66d6R278)
a new functionality is introduced to cover an existing issue. The
existing issue is: the fact that we are retrying the failed test in
cypress in the `parallel_serverless` script, leads to two junit xml
result files completely identical with only difference the execution
time and the timestamps. This change will take one by one the xml
outputs, transform them exactly as it was happening before and then save
the file, but also remove the time and timestamp fields, convert it to a
string and add it to a "state" list. Then in a next file if it is
already parsed and saved to the list having the exact same results
within, it deletes the file instead of saving it transformed.
The problem before this fix was the fact that when two xml outputs
existed, a github ticket was created and when parsing-uploading the
second file it was immediately failing for a second time as well. This
means that `new-failure` notification was never triggered after the
github actions flow split, and the existing failure was always
triggered, something that most teams have disabled.
With the fix, the identical files are parsed but only once uploaded and
the new failure flow works again.
Closes https://github.com/elastic/kibana/issues/185601
## Summary
Using non-compliant algorithms with Node Cryptos createHash function
will cause failures when running Kibana in FIPS mode.
We want to discourage usages of such algorithms.
---------
Co-authored-by: Sid <siddharthmantri1@gmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR adds the executed command line to the failures page.
We tweak the reporters to export the executed command to the junit xmls,
then we read those attributes after parsing the results.
The tests needed some adjustment, because they're very brittle, and
don't seem to be very accurate anymore.
Closes: https://github.com/elastic/kibana-operations/issues/127
Check out the `[logs]` for the failed tests here
(ftr/jest/jest_integration):
https://buildkite.com/elastic/kibana-pull-request/builds/218457
## 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>
## 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 PR adds `NoSuchSessionError: invalid session id` to the irrelevant
failures, so that we don't open github issues for it.
The issue is often related to test infrastructure (worker) and occurs
when Chrome process is reaching the available memory limits. It doesn't
fail regularly but when it fails multiple github issues are
[reported](https://github.com/elastic/kibana/issues?q=is%3Aissue+NoSuchSessionError+is%3Aopen)
and we usually just close them as CI related.
## Summary
We recently had a
[failure](https://buildkite.com/elastic/kibana-on-merge/builds/29020#018792bc-498a-46d1-9343-fb791823d92e)
while calling Github API to open new issue:
```
2023-04-18 07:56:26 CEST ERROR Error: [post https://api.github.com/repos/elastic/kibana/issues] 422 Unprocessable Entity Error: {"message":"Validation Failed","errors":[{"resource":"Issue","code":"custom","field":"body","message":"body is too long"},{"resource":"Issue","code":"custom","field":"body","message":"body is too long (maximum is 65536 characters)"}],"documentation_url":"https://docs.github.com/rest/reference/issues#create-an-issue"}
2023-04-18 07:56:26 CEST at GithubApi.request (github_api.ts:177:17)
2023-04-18 07:56:26 CEST at processTicksAndRejections (node:internal/process/task_queues:96:5)
2023-04-18 07:56:26 CEST at GithubApi.createIssue (github_api.ts:106:18)
2023-04-18 07:56:26 CEST at createFailureIssue (report_failure.ts:39:10)
2023-04-18 07:56:26 CEST at description (failed_tests_reporter_cli.ts:153:28)
2023-04-18 07:56:26 CEST at run.ts:70:7
2023-04-18 07:56:26 CEST at withProcRunner (with_proc_runner.ts:29:5)
2023-04-18 07:56:26 CEST at run (run.ts:69:5)
```
It seems like some test might have a very long failure message that
reaches Github body length limit and causes a failure.
Since mocha truncates failure message to 8192 chars, I thought it might
be a good option for Github issues as well (Having too long message is
not very useful anyway)
## 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>
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.
* [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>
