## Summary
This PR aims at relocating some of the Kibana modules (plugins and
packages) into a new folder structure, according to the _Sustainable
Kibana Architecture_ initiative.
> [!IMPORTANT]
> * We kindly ask you to:
> * Manually fix the errors in the error section below (if there are
any).
> * Search for the `packages[\/\\]` and `plugins[\/\\]` patterns in the
source code (Babel and Eslint config files), and update them
appropriately.
> * Manually review
`.buildkite/scripts/pipelines/pull_request/pipeline.ts` to ensure that
any CI pipeline customizations continue to be correctly applied after
the changed path names
> * Review all of the updated files, specially the `.ts` and `.js` files
listed in the sections below, as some of them contain relative paths
that have been updated.
> * Think of potential impact of the move, including tooling and
configuration files that can be pointing to the relocated modules. E.g.:
> * customised eslint rules
> * docs pointing to source code
> [!NOTE]
> * This PR has been auto-generated.
> * Any manual contributions will be lost if the 'relocate' script is
re-run.
> * Try to obtain the missing reviews / approvals before applying manual
fixes, and/or keep your changes in a .patch / git stash.
> * Please use
[#sustainable_kibana_architecture](https://elastic.slack.com/archives/C07TCKTA22E)
Slack channel for feedback.
Are you trying to rebase this PR to solve merge conflicts? Please follow
the steps describe
[here](https://elastic.slack.com/archives/C07TCKTA22E/p1734019532879269?thread_ts=1734019339.935419&cid=C07TCKTA22E).
#### 3 packages(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/code-editor` |
`src/platform/packages/shared/shared-ux/code_editor/impl` |
| `@kbn/code-editor-mock` |
`src/platform/packages/shared/shared-ux/code_editor/mocks` |
| `@kbn/monaco` | `src/platform/packages/shared/kbn-monaco` |
<details >
<summary>Updated relative paths</summary>
```
src/platform/packages/shared/kbn-monaco/jest.config.js:12
src/platform/packages/shared/kbn-monaco/tsconfig.json:2
src/platform/packages/shared/kbn-monaco/tsconfig.type_check.json:2
src/platform/packages/shared/shared-ux/code_editor/impl/jest.config.js:12
src/platform/packages/shared/shared-ux/code_editor/impl/tsconfig.json:16
src/platform/packages/shared/shared-ux/code_editor/impl/tsconfig.json:2
src/platform/packages/shared/shared-ux/code_editor/impl/tsconfig.type_check.json:18
src/platform/packages/shared/shared-ux/code_editor/impl/tsconfig.type_check.json:2
src/platform/packages/shared/shared-ux/code_editor/impl/tsconfig.type_check.json:25
src/platform/packages/shared/shared-ux/code_editor/impl/tsconfig.type_check.json:28
src/platform/packages/shared/shared-ux/code_editor/impl/tsconfig.type_check.json:31
src/platform/packages/shared/shared-ux/code_editor/impl/tsconfig.type_check.json:34
src/platform/packages/shared/shared-ux/code_editor/impl/tsconfig.type_check.json:37
src/platform/packages/shared/shared-ux/code_editor/impl/tsconfig.type_check.json:40
src/platform/packages/shared/shared-ux/code_editor/mocks/tsconfig.json:16
src/platform/packages/shared/shared-ux/code_editor/mocks/tsconfig.json:2
src/platform/packages/shared/shared-ux/code_editor/mocks/tsconfig.type_check.json:18
src/platform/packages/shared/shared-ux/code_editor/mocks/tsconfig.type_check.json:2
src/platform/packages/shared/shared-ux/code_editor/mocks/tsconfig.type_check.json:25
```
</details>
## Summary
This PR adds support for explicit indication whether endpoint is
restricted to operator only users.
### Context
1. If user has [all operator
privileges](https://github.com/elastic/elasticsearch/blob/main/x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/operator/DefaultOperatorOnlyRegistry.java#L35-#L53)
granted, but is not listed as operator in `operator_users.yml`, ES would
throw an unauthorized error.
2. If user is listed as operator in `operator_users.yml`, but doesn't
have necessary privileges granted, ES would throw an unauthorized error.
3. It’s not possible to determine if a user is operator via any ES API,
i.e. `_has_privileges`.
4. If operator privileges are disabled we skip the the check for it,
that's why we require to explicitly specify additional privileges to
ensure that the route is protected even when operator privileges are
disabled.
### 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
__Relates: https://github.com/elastic/kibana/issues/196271__
### How to test
1. Add your user to the operators list
1bd8144924/packages/kbn-es/src/serverless_resources/operator_users.yml (L4)
or use existing user from the list to log in.
2. Run ES and Kibana serverless
3. Change any endpoint or create a new one with the following security
config
```
security: {
authz: {
requiredPrivileges: [ReservedPrivilegesSet.operator],
},
},
```
4. Check with enabled and disabled operator privileges (set
`xpack.security.operator_privileges.enabled`)
## Release Note
Added support for explicit indication whether endpoint is restricted to
operator only users at the route definition level.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Relates to https://github.com/elastic/kibana/issues/181995
This PR updates the examples to include availability information and
another description.
Co-authored-by: Jean-Louis Leysens <jeanlouis.leysens@elastic.co>
Saved objects declared as `hidden` can only be accessed with a client
that explicitly includes hidden types.
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
---------
Co-authored-by: Alejandro Fernández Haro <afharo@gmail.com>
## Summary
- Added section for migrating routes created by utility function.
- Added `patch` method to route methods in eslint rule.
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
* Remove duplicated “File service” entry from nav
* Move Screenshotting to main Tutorials section in nav
* Add “Updating Puppeteer and Chromium” to nav as a sub-item of
screenshotting
* Move files for Screenshotting/Chromium out of the SharedUX space to
`dev_docs/tutorials/screenshotting`
## Summary
Changed import path for Kibana Core Public imports, previous was not
working. New import path reflects what I found elsewhere in the
codebase, and works.
## Summary
Added documentation for the security route configuration.
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Add Recently Viewed dev docs
---------
Co-authored-by: Tim Sullivan <tsullivan@users.noreply.github.com>
Co-authored-by: Clint Andrew Hall <clint@clintandrewhall.com>
`kibDevTutorialsServerlessProjectNavigation`
was changed to
`kibDevTutorialsSolutionNavigation`
in
https://github.com/elastic/kibana/pull/193988
but they missed one. This PR fixes the failing docs.elastic.dev build.
## Summary
- Fixes an issue where the container would not be setup or start
properly if the repo wasn't name `kibana`
- Adds limitations section to docs
## Summary
It’s common request for Dev teams to run specific journeys on a PR to
compare performance metrics against the `main` branch. These requests
usually focus on a particular area, such as the Dashboard or Discover
app.
To streamline the process, this PR groups relevant journeys into
categories that can be triggered through an environment variable. For
example, setting `JOURNEYS_GROUP=dashboard` will execute only the three
dashboard-specific journeys, which are (usually) sufficient for
evaluating the performance impact of code changes within the Dashboard
app.
Current Process for Triggering Performance Builds:
- Create a new kibana-single-user-performance
[build](https://buildkite.com/elastic/kibana-single-user-performance#new)
- Provide the following arguments:
Branch: `refs/pull/<PR_number>/head`
Under Options, set the environment variable:
`JOURNEYS_GROUP=<group_name>`
Currently supported journey groups:
- kibanaStartAndLoad
- crud
- dashboard
- discover
- maps
- ml
[Build example
](https://buildkite.com/elastic/kibana-single-user-performance/builds/14427)
Each group focuses on a specific set of journeys tied to its respective
area in Kibana, allowing for more targeted performance testing. Since
running group takes ~5-10 min on bare metal worker, it should not delay
the regular (every 3h) runs against `main` branch
test locally with `node scripts/run_performance.js --group <group_name>`
## Summary
As titled. This PR outlines several use cases around plugin optimization
that can be helpful to engineers. This PR is part of a series, but
divided to make review easier.
It also reworks the navigation a bit to make the optimization section a
bit more clear.
## Summary
- Closeselastic/kibana-operations#101
This PR adds a [Dev Container](https://containers.dev/) to utilize for
Kibana local development in an isolated environment. The original
intention was to create a local environment for FIPS development because
setting up Kibana in FIPS mode is complicated and has the potential to
break the user's OS. However, it has been altered to allow for general
development if an engineer chooses as well. The idea is for this be a
cost efficient replacement for
[kibana-remote-dev](https://github.com/elastic/kibana-remote-dev)
eventually.
### Testing
- In VS Code you should be able to use the `Dev Containers: Clone GitHub
Pull Request in Named Container Volume...` command from the Command
Palette (F1) to easily test this PR.
- See the
[docs](bd125fc230/dev_docs/getting_started/setting_up_a_development_env.mdx (using-the-kibana-dev-container-optional))
for additional information on setting up the Dev Container.
### Bazel
I tried many different solutions to copy the local Bazel cache into the
container to speed up bootstrap, but it either would break Bazel or
didn't provide any meaningful boost in performance. I opted to forgo
keeping it in this PR due to the complexity and since we're planning to
phase out Bazel in the future anyways.
Closes#176097
## Summary
Adds 'Key concepts' developer documentation for Encrypted Saved Objects,
covering the basic theory, usage, and maintenance for encrypted saved
objects in Kibana.
Paired with @ThomThomson to expand Embeddable documentation with
"Guiding principles" and "Best practices"
PR also moves overview to src/plugins/embeddables/README.md. Then, this
markdown is displayed in the embeddable example application as well.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Devon Thomson <devon.thomson@elastic.co>
Having the same thing in multiple places is confusing and hard to
maintain. Embeddable documentation is exposed via developer examples.
This PR removes embeddable documentation in README and dev-docs and
points those locations to the single location for embeddable
documenation.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Added documentation explaining how SO migrations on serverless work
## Preview
<img width="741" alt="Screenshot 2024-03-22 at 16 15 13"
src="2217c01f-8447-4f22-a782-a07ff221aa42">
## Summary
For ES|QL charts the formula api should be redundant. This is going to
make the api lighter as there is no need to import the lens plugin if
you want to use the builder to create ES|QL charts.
## Summary
Moving synthtrace clients init inside kbn-journeys:
esArchiver does not always solve the issue with data generation. We
already have afew journeys using Synthtrace instead and expect more to
come.
In order to simplify the process of creating new journeys, this PR moves
Synthtrace client initialisation into kbn-journey package and exposes a
way to define client type, generator function & its input arguments:
```
import { Journey, SynthtraceOptions } from '@kbn/journeys';
import { subj } from '@kbn/test-subj-selector';
import { generateApmData } from '../synthtrace_data/apm_data';
export const journey = new Journey({
synthtrace: {
type: 'apm',
generator: generateApmData,
options: {
from: new Date(Date.now() - 1000 * 60 * 15),
to: new Date(Date.now() + 1000 * 60 * 15),
},
},
})
```
PR also needs review from teams who use Synthtrace to understand if the implementation is matching expectations.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
The source code classifier we currently have was incorrectly classifying
e2e journey files as `non-package` instead of `tests or mocks` as it was
not using the name standards we used for FTR files.
We could have created a `functional-tests` package for the performance
folder (which is what we want to do in the future) but because we don't
have the feature to create ownerless packages it would not be easy to
find a given owner for that folder.
As such I'm just opting for a second solution which is applying the same
name standards to this journeys folder as we have for FTR and changing a
little the classifier to recognise it.
This should fix the problem found at
https://github.com/elastic/kibana/pull/178017.
Co-authored-by: Alex Szabo <alex.szabo@elastic.co>
