## Summary
Updated `js-yaml` to `4.1.0`.
This PR also introduces a type override for the `js-yaml` load function
to maintain compatibility across the codebase. Specifically, updated
type definition of the load function looks as follows:
```typescript
function load<T = any>(str: string, opts?: jsyaml.LoadOptions): T;
```
The original type definition of the load function in `js-yaml` changed
from `any` to `unknown`. This change would require extensive type
updates throughout the entire repository to accommodate the `unknown`
type. To avoid widespread type changes and potential issues in the
codebase, the type is overriden back to `any` for now.
This is a temporary measure, we plan to address the necessary type
changes in subsequent PRs, where teams will gradually update the
codebase to work with the `unknown` type.
### Checklist
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
## Release note
Updated `js-yaml` to `4.1.0`.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Maxim Palenov <maxim.palenov@elastic.co>
## Summary
Updates usage of `js-yaml` `load` and `dump` to `safeLoad` and
`safeDump`, in preparation for a major version update of dependency,
where the default behavior will be that of the safe function variants.
## Note to reviewers
`safeDump` will throw if it encounters invalid types (e.g. `undefined`),
whereas the `dump` function will still write the file including the
invalid types. This may have an affect within your use cases - if
throwing is not acceptable or is unhandled. To avoid this the
`skipInvalid` option can be used (see
https://github.com/nodeca/js-yaml#dump-object---options-) - this will
write the file, stripping out any invalid types from the input.
Please consider this when reviewing the changes to your code. If the
`skipInvalid` option is needed, please add it, or let us know to make
the change.
---------
Co-authored-by: Sid <siddharthmantri1@gmail.com>
Co-authored-by: “jeramysoucy” <jeramy.soucy@elastic.co>
Co-authored-by: Elena Shostak <elena.shostak@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Maxim Palenov <maxim.palenov@elastic.co>
## Summary
Part of #186515
Split FTR configs manifest into multiple files based on distro
(serverless/stateful) and area of testing (platform/solutions)
Update the CI scripts to support the change, but without logic
modification
More context:
With this change we will have a clear split of FTR test configs owned by
Platform and Solutions. It is a starting point to make configs
discoverable, our test pipelines be flexible and run tests based on
distro/solution.
