## Summary
Switch to one matcher w/ all code owner patterns rather than separate
matchers for each code owner pattern. Reduces the run time of
`scripts/check_ftr_code_owners.js` by ~10x.
### Before
```console
▶ node scripts/check_ftr_code_owners.js
info Reading CODEOWNERS file
info Checking ownership for 8653 test files (this will take a while)
info Ownership check complete (took 18.89 s)
succ All test files have a code owner. 🥳
```
#### After
```console
▶ node scripts/check_ftr_code_owners.js
info Checked 8653 test files in 1.59s
succ All test files have a code owner 🥳
```
## Summary
The following improvements have been made:
- Added `--json` flag to CLI command to output result as JSON
- Terminology updated to more accurately reflect object contents
- Code owner teams are always returned as an array
- Search path validation (is under repo root, exists)
- Proper handling of inline comments
- Better logging for `scripts/check_ftr_code_owners.js`
Existing usage of the `@kbn/code-owners` package has been updated
accordingly, without modifying outcomes.
## Summary
Adds the `node scripts/relocate` functionality, that helps moving
modules to their intended locations, according to the _Sustainable
Kibana Architecture_.
Please refer to the README.md for further details and usage.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
1. Show all packages owned by a specific team
```
node scripts/dependency_ownership -o <owner>
```
2. Identify owners of a specific dependency
```
node scripts/dependency_ownership -d <dependency>
```
3. List dependencies without an owner
```
node scripts/dependency_ownership --missing-owner
```
4. Generate a full dependency ownership report
```
node scripts/dependency_ownership
```
### 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
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
__Closes: https://github.com/elastic/kibana/issues/196767__
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR introduces a new package, **kbn-scout**, designed to streamline
the setup and execution of Playwright tests for Kibana. The `kbn-scout`
package consolidates server management and testing capabilities by
wrapping both the Kibana/Elasticsearch server launcher and the
Playwright test runner. It includes:
- Test and worker-scoped fixtures for reliable setup across test suites
- Page objects combined into the fixture for Kibana UI interactions
- Configurations for seamless test execution in both local and CI
environments (`Cloud` execution is out of scope)
- This package aims to simplify test setup and enhance modularity,
making it easier to create, run, and maintain deployment-agnostic tests,
that are located in the plugin they actually test.
Tests example is available in `x-pack/plugins/discover_enhanced` plugin
under `ui_tests` folder
How to run:
1) As a single script (servers + tests):
```
node scripts/scout_test.js --config=x-pack/plugins/discover_enhanced/ui_tests/playwright.config.ts --serverless=es
```
2) Start servers first
```
node scripts/scout_start_servers.js --serverless=es
```
then run tests:
```
npx playwright test --config=x-pack/plugins/discover_enhanced/ui_tests/playwright.config.ts
```
if you have Playwright plugin in IDEA, just use it to run tests files
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
[dependency-cruiser](https://github.com/sverweij/dependency-cruiser/tree/main)
is used for building dependency graph.
### Show all dependencies for a specific package/plugin or directory
#### Run for all plugins
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins -o ./tmp/deps-result-all.json
```
#### Run for single plugin
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution -o ./tmp/deps-result-single.json
```
#### Run for multiple plugins
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution x-pack/plugins/security -o ./tmp/deps-result-multiple.json
```
#### Run for `x-pack/packages`
```bash
bash scripts/dependency_usage.sh -p x-pack/packages -o ./tmp/deps-packages-1.json
```
#### Run for `packages`
```bash
bash scripts/dependency_usage.sh -p packages -o ./tmp/deps-packages-2.json
```
#### Benchmark
| Analysis | Real Time | User Time | Sys Time |
|-----------------------|-------------|-------------|------------|
| All plugins | 7m 21.126s | 7m 53.099s | 20.581s |
| Single plugin | 31.360s | 45.352s | 2.208s |
| Multiple plugins | 36.403s | 50.563s | 2.814s |
| x-pack/packages | 6.638s | 12.646s | 0.654s |
| packages | 25.744s | 39.073s | 2.191s |
#### Show all packages/plugins within a directory that use a specific
dependency
```sh
bash scripts/dependency_usage.sh -d rxjs -p x-pack/plugins/security_solution
```
---
#### Show all packages/plugins within a directory grouped by code owner
```sh
bash scripts/dependency_usage.sh -d rxjs -p x-pack/plugins -g owner
```
---
#### Group by code owner with adjustable collapse depth for fine-grained
grouping
**Fine-grained grouping**:
```sh
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution -g owner --collapse-depth 4
```
**Collapsed grouping**: groups the results under a higher-level owner
(e.g., `security_solution` as a single group).
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution -g owner --collapse-depth 1
```
---
#### Show all dependencies matching a pattern (e.g., `react-*`) within a
package
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution -d 'react-*' -o ./tmp/result.json
```
### 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: https://github.com/elastic/kibana/issues/196767__
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR introduces a script that allows developers to run CodeQL
analysis locally. It uses a Docker container with prebuilt CodeQL
queries to facilitate easy setup and execution.
The script has the following key steps:
- Creating a CodeQL database from the source code. The database is
essentially a representation of the codebase that CodeQL uses to analyze
for potential issues.
- Running the analysis on the created database,
`javascript-security-and-quality` suit is used.
### Usage
```
bash scripts/codeql/quick_check.sh -s path/to/your-source-dir
```
For example
```
bash scripts/codeql/quick_check.sh -s ./x-pack/plugins/security_solution/public/common/components/ml/conditional_links
```
The `-s` option allows you to specify the path to the source code
directory that you wish to analyze.
### Why custom Docker file?
Checked the ability to use MSFT image for local run
https://github.com/microsoft/codeql-container. Turned out it has several
problems:
1. The published one has an error with [execute
permissions](https://github.com/microsoft/codeql-container/issues/53).
2. Container has outdated nodejs version, so it didn't parse our syntax
(like `??`) and failed.
3. The technique used in the repository to download the CodeQL binaries
and precompile the queries is outdated in the sense that GitHub now
offers pre-compiled queries you can just download. Follow this
[comment](https://github.com/microsoft/codeql-container/issues/53#issuecomment-1875879512).
Taking this into consideration I have created a lightweight docker image
without extraneous dependencies for go/.net/java.
## Context and interdependencies issues
There are issues sometimes when analyze run returns no results,
particularly when analyzing a single folder.
It might be due to the missing context for the data flow graph CodeQL
generates or context for interdependencies. This is actually a trade off
of running it locally for a subset of source directories. We need to
explicitly state that in the documentation and advise to expand the
scope of source code directories involved for local scan.
Documentation for triaging issues will be updated separately.
__Closes: https://github.com/elastic/kibana/issues/195740__
## Summary
Addresses https://github.com/elastic/kibana-team/issues/1175
As part of the **Sustainable Kibana Architecture** initiative, this PR
sets the foundation to start classifying plugins in isolated groups,
matching our current solutions / project types:
* It adds support for the following fields in the packages' manifests
(kibana.jsonc):
* `group?: 'search' | 'security' | 'observability' | 'platform' |
'common'`
* `visibility?: 'private' | 'shared'`
* It proposes a folder structure to automatically infer groups:
```javascript
'src/platform/plugins/shared': {
group: 'platform',
visibility: 'shared',
},
'src/platform/plugins/internal': {
group: 'platform',
visibility: 'private',
},
'x-pack/platform/plugins/shared': {
group: 'platform',
visibility: 'shared',
},
'x-pack/platform/plugins/internal': {
group: 'platform',
visibility: 'private',
},
'x-pack/solutions/observability/plugins': {
group: 'observability',
visibility: 'private',
},
'x-pack/solutions/security/plugins': {
group: 'security',
visibility: 'private',
},
'x-pack/solutions/search/plugins': {
group: 'search',
visibility: 'private',
},
```
* If a plugin is moved to one of the specific locations above, the group
and visibility in the manifest (if specified) must match those inferred
from the path.
* Plugins that are not relocated are considered: `group: 'common',
visibility: 'shared'` by default. As soon as we specify a custom
`group`, the ESLINT rules will check violations against dependencies /
dependants.
The ESLINT rules are pretty simple:
* Plugins can only depend on:
* Plugins in the same group
* OR plugins with `'shared'` visibility
* Plugins in `'observability', 'security', 'search'` groups are
mandatorily `'private'`.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Related https://github.com/elastic/kibana/issues/193473
Add initial implementation of the knowledge base artifact builder. This
PR only introduces the builder script, it doesn't do anything about
automation.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Node script to report ownership of a given file in our repo.
The script's source of truth is `.github/CODEOWNERS`, which is generated
by `@kbn/generate`
In order to reach the goal of have zero files without code ownership,
this is one small step along the way.
### To Test
#### Happy Path
`node scripts/get_owners_for_file.js --file
packages/kbn-ace/src/ace/modes/index.ts`
```
succ elastic/kibana-management
```
#### Unknown Path
`node scripts/get_owners_for_file.js --file some-file.txt`
```
ERROR Ownership of file [some-file.txt] is UNKNOWN
```
#### Error Path
`node scripts/get_owners_for_file.js`
```
ERROR Missing --flag argument
node scripts/get_owners_for_file.js
Report file ownership from GitHub CODEOWNERS file.
Options:
--file Required, path to the file to report owners for.
--verbose, -v Log verbosely
--debug Log debug messages (less than verbose)
--quiet Only log errors
--silent Don't log anything
--help Show this message
```
### Notes
Along with this small pr, next will be to ensure owners are assigned to
all ES and KBN Archives. See more info in the link below:
Contributes to: https://github.com/elastic/kibana/issues/192979
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 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
Moving common services to respective new homes.
Resolves: https://github.com/elastic/kibana/issues/188541
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
This PR is the final step needed for us to re-enable pointer compression
on serverless.
It introduces a cli later used in a CI check that will prevent the
addition of new native modules on production as discussed and agreed
with Luke and Brandon previously.
It also removes the usages of `cbor-x` and replaces those with a
wrapping package `@kbn/cbor` which relies on the implementation coming
from `borc` with no native modules involved.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Use typescript's async processes to start quick checks in parallel 👍
Check out these for runs:
- happy case:
https://buildkite.com/elastic/kibana-pull-request/builds/227443#01914ca3-1f0d-4178-b539-263fbc588e98
- some broken checks:
https://buildkite.com/elastic/kibana-pull-request/builds/228957#01917607-f7bd-4e08-8c70-7fdc3f9c12d1
Benefits:
- with this (+more CPU) we can speed up the quick-check step's runtime,
from ~15m to ~7m.
- the added benefit is that all checks run so that we won't bail on the
1st one
Disadvantage:
- uglier error output, since we collect the logs asynchronously, and
print it only upon failure
- ~no output printed for happy checks (can be changed)~
Extra:
- additionally, `yarn quick-checks` will now allow devs to run these
checks locally (adjustments made so that the checks won't fail in local
dev)
- added the option to declare a 'context' for tooling loggers, so we can
identify which script logs
Solves 2/3 of https://github.com/elastic/kibana-operations/issues/124
(+speedup)
## 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
At the moment, our package generator creates all packages with the type
`shared-common`. This means that we cannot enforce boundaries between
server-side-only code and the browser, and vice-versa.
- [x] I started fixing `packages/core/*`
- [x] It took me to fixing `src/core/` type to be identified by the
`plugin` pattern (`public` and `server` directories) vs. a package
(either common, or single-scoped)
- [x] Unsurprisingly, this extended to packages importing core packages
hitting the boundaries eslint rules. And other packages importing the
latter.
- [x] Also a bunch of `common` logic that shouldn't be so _common_ 🙃
### For maintainers
- [x] 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
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.
Update i18n tools after the main packages upgrade. This upgrade makes
use of formatJS tooling instead of fully implementing the parsers
ourselves. It also changes our custom AST parsing from babel to the
typescript compiler.
- [x] i18n exrtract
- [x] i18n check
- [x] i18n integrate
- [x] add test cases for formatjs runner
- [x] Make sure all CLI flags are handled properly
- [x] Update tooling readme
Closes https://github.com/elastic/kibana/issues/180616
Closes https://github.com/elastic/kibana/issues/187703
### Note to reviewers
Teams outside operations and core are probably requested to review
because the `i18n_check` fixed malformed i18n messages in your plugins.
Please check and approve :elasticheart:
This PR removes the usage of the native module version of `re2` and
replaces it with a js port called `re2js`.
It also ends our usage of native node modules in production and it
removes the task from the build as well. Further steps will be taken
along our strategy to avoid future usages of native node modules in prod
environments.
Close https://github.com/elastic/kibana/issues/181992
## Summary
First iteration of a CLI to capture an OAS snapshot.
## How to test
Run `node ./scripts/capture_oas_snapshot.js --update --include-path
/api/status` and see result in `oas_docs/bundle.json`.
If you have the [bump CLI](https://www.npmjs.com/package/bump-cli)
installed you can preview the hosted output with `bump preview
./oas_docs/bundle.json`
## Notes
* Added ability to filter by `version`, `access` (public/internal) and
excluding paths explicitly to the OAS generation lib
* Follows the same general pattern as our other "capture" CLIs like
`packages/kbn-check-mappings-update-cli`
* Result includes only `/api/status` for now, waiting for other paths to
add missing parts
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR is just deleting 4 custom overrides `.prettierrc` files and
applying the auto fixes resulting from those changes. We've found some
automation tasks were broken because we don't have a common code style
across the codebase and we want to optimize for that with that change.
Required for: https://github.com/elastic/kibana-operations/pull/93
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
The existence of `kibanaUrl` in the default parameters leads to the SAML
role provider being enabled for `yarn es docker --ssl` and then ES
crashing on startup. This option should only be a default for `yarn es
serverless --ssl`
## Summary
Dealing with circular dependencies between plugins has become a sharp
pain point for anyone developing plugins in Kibana.
### Providing dependencies to a plugin
First, a plugin defines its dependencies in its `kibana.jsonc` file as
one of three types:
- `required` - the dependency must be present and enabled -- will be
guaranteed in the lifecycle
- `optional` - the dependency can be missing or disabled -- will be
`undefined` in the lifecycle
- `requiredBundle` - the dependency is required as static code only --
will not be present in the lifecycle
Missing or circular dependencies are detected by the Kibana platform
when it starts.
### Providing dependencies in code
Our plugins are written in and type-checked by Typescript. As such, each
plugin needs to maintain Typescript types defining what the platform is
providing. This is done manually, and there is no enforcement mechanism
between that and the plugin Typescript types. If these dependency
definitions are inconsistent or stale, it can lead to host of issues:
- optional plugins typed as required that are disabled crash the plugin
at runtime;
- plugins that are no longer used still included in dependency checks;
- plugins marked as required or optional that are actually required
bundles.
- etc.
### Dependencies with side-effects
One of the interesting things that has come out of this has been
identifying plugins that provide dependent logic through side-effects,
rather than lifecycles.
As an example, `licensing` provides a lifecycle contracts, but also a
[route handler
context](https://github.com/elastic/kibana/blob/main/x-pack/plugins/licensing/server/licensing_route_handler_context.ts)
as middleware for a dependent plugin. Unfortunately, while this
dependency can be stated as `required` in a dependent plugin's
`kibana.jsonc`, the fact that this is a side-effect makes it incredible
difficult to understand the dependency without searching the code.
<img width="735" alt="Screenshot 2023-12-13 at 10 08 00 AM"
src="b4201c86-4811-4506-b2d0-be5bf8c372b0">
So the side-effect is more or less hidden from developers. This is
likely why we see other plugins using the lifecycle
[logic](https://github.com/elastic/kibana/blob/main/src/plugins/maps_ems/public/kibana_services.ts#L33-L37),
or copy-pasting licensing check code
[[1](https://github.com/elastic/kibana/blob/main/x-pack/plugins/actions/server/lib/license_state.ts),
[2](https://github.com/elastic/kibana/blob/main/x-pack/plugins/alerting/server/lib/license_state.ts)],
or relying on the route context side-effect.
## Proposed (initial) solution
This script is an initial attempt to both identify these problems and
surface a plugin's dependencies in a useful way. In addition, the script
will warn if the classes aren't typed well, not typed at all, or even
don't extend the `core` `Plugin` class.
<img width="1426" alt="Screenshot 2023-12-13 at 12 37 25 AM"
src="e044afb7-26f5-4d96-92db-d2eb0a3dfc6e">
<img width="1413" alt="Screenshot 2023-12-13 at 12 38 07 AM"
src="69217a34-9840-4d32-98de-eeeb863d4a50">
<img width="1071" alt="Screenshot 2023-12-13 at 12 38 35 AM"
src="57736027-2d10-44bf-8230-29fdb8b77cb2">
For side-effects, identifying them is key, and then refactoring the
plugins to provide appropriate logic in the `start` or `setup`
contracts.
## Next steps
- [x] refine the logic
- [ ] write tests
- [ ] add `--fix` option
I'm also considering (in another PR), outputting a consistent type
definition file-- perhaps `kibana.d.ts`-- to the plugin from which the
implementing classes could `Omit<>` or `Pick<>` the relevant contracts.
## 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)
```
Attempting to merge #170852 again now that the release artefact step has
been fixed as part of https://github.com/elastic/kibana/pull/171457
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
Related to [#166340](https://github.com/elastic/kibana/issues/166340)
## Summary
Add mock identity provider and utils to test serverless user roles.
## Screenshot
### 1. Login selector
<img width="767" alt="Screenshot 2023-11-08 at 15 18 18"
src="82b4a29f-65b4-45d2-bed3-6d9f74043c48">
### 2. Single sign on screen
<img width="437" alt="Screenshot 2023-11-09 at 12 30 46"
src="3d5b6f26-5409-4169-a627-bcf6d09836d9">
### 3. User profile page
<img width="1041" alt="Screenshot 2023-11-08 at 17 36 22"
src="50bd4a5a-f9a8-4643-9384-9a352701b011">
## Testing
SAML is only supported by ES when running in SSL mode.
1. To test the mock identity provider run a serverless project in SSL
mode using:
```bash
yarn es serverless --ssl
yarn start --serverless=es --ssl
```
2. Then access Kibana and login in using "Continue as Test User".
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
## Summary
Continuation on: #167980
Now that we have the snapshots created for merges, we can compare the
existing snapshots.
This PR creates a CLI for grabbing and comparing these snapshots.
The CLI looks like this:
```
node scripts/snapshot_plugin_types compare --from <rev|filename|url> --to <rev|filename|url> [--outputPath <outputPath>]
Compares two Saved Object snapshot files based on hashes, filenames or urls.
Options:
--from The source snapshot to compare from. Can be a revision, filename or url.
--to The target snapshot to compare to. Can be a revision, filename or url.
--outputPath The path to write the comparison report to. If omitted, raw JSON will be output to stdout.
--verbose, -v Log verbosely
```
- Adds an entrypoint, `node scripts/yarn_deduplicate` for fixing
duplicated packages via npm package `yarn-deduplicate`
- Fixes existing duplicated packages
- Adds a CI check verifying no duplicated packages have been added.
There are currently two exclusions - all types packages which causes
other checks to break, and axe-core, which does not follow semver.
Closes https://github.com/elastic/kibana/issues/125712
## Goal
We'd like to increase visibility to when Saved Object migrations and
schema changes are added to serverless releases.
## Plan
- add post-build step to export Saved Object schema snapshot, upload it
to google storage, by commit hash.
- build comparison logic, that when given 2 hashes (e.g.: #current ->
#to-be-released) it can highlight schema changes
- display the output from the comparison where it would make most sense,
ideas:
- prior to release, as a script that can be ran (or a browser-based
inspector)
- prior to release, as a buildkite step, that displays the output, and
waits for a confirmation on it
- during the quality-gating, as an output during the quality-gate run,
to be confirmed by the RM
## Summary
The PR intends to satisfy the first step of the plan, to add a
post-merge step to snapshot SO schema/migration states for later use.
Example run:
https://buildkite.com/elastic/kibana-pull-request/builds/165992#018b0583-c575-47f4-bade-7b45f6cf3f4d
The files are not public, they require google cloud access, but could be
accessed by scripts we create.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fixes https://github.com/elastic/kibana/issues/159410
This PR adds a new package `kbn-generate-console-definitions` that will
eventually replace the package `kbn-spec-to-console`. It also adds a new
command to use the script in the new package. The new command can be
used as following:
- `node scripts/generate_console_definitions.js --source
<PATH_TO_ES_SPECIFICATION_REPO>` where `PATH_TO_ES_SPECIFICATION_FOLDER`
is the absolute path to the root of the [ES specification
repo](https://github.com/elastic/elasticsearch-specification), for
example `/Users/yulia/elastic/elasticsearch-specification`. This command
will generate autocomplete definitions in the folder
`KIBANA_ROOT/src/plugins/console/server/lib/json/generated`.
- Optionally `--dest` parameter can be passed to generate definitions in
a different folder, relative to `KIBANA_ROOT`.
Basic script functionality was implemented in this PR:
- [x] Create the folder if doesn't exist yet
- [x] Remove all files in the folder before generating definitions
- [x] Load the specification schema and parse each endpoint
- [x] Create a file for each endpoint with the endpoint name, methods,
patterns and doc urls.
Functionality that will be added in follow up PRs:
- Url paramaters
- Request body parameters
- Availability property
- Unit test for script functions
### How to test
1. Checkout ES specification repo
2. Run the command with `node scripts/generate_console_definitions.js
--source <ES_SPECIFICATION_REPO> --emptyDest` where
`<ES_SPECIFICATION_REPO>` is the absolute path to the root of the ES
specification repo
3. Check the changes to the generated files in the folder
`/KIBANA_REPO/src/plugins/console/server/lib/spec_definitions/json/generated`
and make sure they have a correct endpoint name, patterns, methods and
doc links. We are not generating any url params, request body params or
availability property for now.
4. Change the constant in the file
`KIBANA_REPO/src/plugins/console/common/constants/autocomplete_definitions.ts`
to a non-existent folder. Run the script `node
scripts/generate_console_definitions.js --source
<ES_SPECIFICATION_REPO>` and check that the folder has been created
successfully
5. Re-run the command without `--emptyDest` flag targeting a folder that
already contain some files. Check that the script fails and doesn't
silently remove existing files
6. Run the help command `node scripts/generate_console_definitions.js
--help` and check if the help message makes sense
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Alison Goryachev <alisonmllr20@gmail.com>
## Summary
Resolves https://github.com/elastic/kibana/issues/136856
- Add async keyword where it should have been.
- Split archive into kbn and es archives...
instigated by Pierre's comment:
https://github.com/elastic/kibana/issues/136856#issuecomment-1253609280
- Note: Had to use both archive types as
one archive is "hidden", and cannot be accessed via the kbn client.
- Unload via Pierre's "new" clean method.
- Add shell fn to print out server's currently loaded so's, with user
and pass hardcoded for local dev.
## Summary
This PR adds a technical control to prevent incompatible mappings
changes. These include:
1. Removing mapped fields. For the foreseeable future we require that
teams only introduce new fields - in short: this avoids the "reindex"
step in our migrations.
2. Changing the type of a field. We leverage ES to determine whether a
given set of mappings can be applied "on top" of another. Similarly,
this avoids the "reindex" step in migrations.
The above checks depend on a snapshot of the mappings from `main`, these
are the "current" mappings and are extracted from plugin code. This PR
will bootstrap `main` with an initial set of mappings extracted from
plugins (bulk of new lines added).
## The new CLI
See the added `README.md` for details on how the CLI works.
## How will it work?
Any new PR that introduces compatible mappings changes will result in a
new snapshot being captured, then merged to main for other PRs to merge
and run the same checks against (currently committing new snapshots
happens in the CI check so there is no manual step of maintaining the
snapshot).
## Additional
We should consider combining this CI check with the existing check in
`src/core/server/integration_tests/saved_objects/migrations/check_registered_types.test.ts`.
Hopefully we can automate the check such that no manual review is needed
from Core, not sure how we might cover the hash of the non-mappings
related fields. We could consider narrowing the Jest test to exclude
mappings.
### 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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: spalger <spencer@elastic.co>
After chatting with @KOTungseth, @scottybollinger, and @glitteringkatie
we've decided to add a CI step to the Kibana repo that will run when
changes to next-doc related code is made. This step will checkout the
repository containing configuration for the docs.elastic.dev website
(which is currently private, sorry) and then ensure that the build can
be completed with a local copy of all the repositories. It does this by
reading the `config/content.js` files and cloning all of the
repositories listed, then rewriting the content.js file with a map
telling the build system to read files from the local repos (which are
pre-cached by the packer cache job) and the local Kibana repo (which
represents the changes in the PR).
This script also runs locally by running `node
scripts/validate_next_docs`.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
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>
We just had an issue where two PRs were merged and it caused the limit
of the `triggerActionsUi` bundle to be exceeded, breaking PR builds. The
issue is that we didn't see any indication of this in the on-merge jobs
because we don't produce the PR report for on-merge jobs or ask ci-stats
if we should fail the job. Instead, we just ship the metrics for
baseline purposes. This fixes that problem by adding a `--validate` flag
to `node scripts/ship_ci_stats`, which takes care of sending at least
some ci-stats and will verify that the bundle limits are not exceeded.
Since we didn't catch this issue in the on-merge job the limits were
incorrect for over an hour and merged into many PRs, wasting engineering
and CI time.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR ads a new cli package to allow us to search for package
locations by providing their IDs. I see this as useful as we start
adding more and more packages across different locations.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
