Move all Observability plugins into /x-pack/observability_solution

[CoenWarmer]

Summary

This moves all most Observability plugins in /x-pack into /x-pack/observability_solution.

The changes in this PR are 99% files moves.

The only files that were otherwise changed are:

• tsconfig.json files for every plugin, which needed to be pointed at the base TSConfig file one folder up. Example: "extends": "../../../tsconfig.base.json", => "extends": "../../../../tsconfig.base.json",
• x-pack/i18nrc.json, which has updated folders;
• packages/kbn-babel-preset/styled_components_files.js which needed to be updated to include the updated folder structure.

Edit 21-nov-2023:
As requested these plugins are excluded from the move:

• Observability
• Observability Log Explorer
• Log Explorer

Why even do this??

The Kibana plugin structure supports nesting of plugins by design.

In 2020 there was an initiative to reorganize folder structure according to domain for all plugins. This initiative was not followed up on then. We can do this for the Obs solution now.

Making this change has the following advantages:

• Clearer organisation: It provides a clearer distinction as to what plugins belong to the Observability solution and which do not. Plugins don't need to be prefixed with observability_.
• Supports more discoverability Easier discoverability of techniques, patterns and functions in closely related plugins. Fosters easier sharing, lifting or shameless stealing from your team mates.
• Aids organisational awareness: It is easier as a member of the Observability org to find plugins that your colleagues are working in. Especially as plugin folder names may not correspond to naming used in the UI.
• Supports Tier proposal: Following the discussion around tiering plugins, it provides an easier view on plugins that offer shared functionality or 'signal' plugins.
• Low effort Moving folders is a cheap and easy way to surface which plugins are related to each other. Other approaches such as adding an org key to kibana.jsonc needs code work and approval from Kibana Core.
• Easier tooling management: By having plugins in one folder it is easier to apply consistent tooling such as ESLint rules to all plugins belonging to the Observability group (Slack conversation)

[apmmachine]

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

• /oblt-deploy : Deploy a Kibana instance using the Observability test environments.
• /oblt-deploy-serverless : Deploy a serverless Kibana instance using the Observability test environments.
• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[cauemarcondes]

I honestly don't think it's quite important to move solutions to a specific folder. You can easily work around it by using a workspace in vscode for example.

But if we want to move forward with this, I'd probably name the folder observability_solutions in plural. Also would be nice to keep it consistent across the code base:

• Should we also have the Observability tests in a centralized folder too https://github.com/CoenWarmer/kibana/tree/feat/re-org/x-pack/test?
• And Observability packages https://github.com/CoenWarmer/kibana/tree/feat/re-org/packages?

[CoenWarmer]

I honestly don't think it's quite important to move solutions to a specific folder. You can easily work around it by using a workspace in vscode for example.

How would that work with ESLint rule config?

But if we want to move forward with this, I'd probably name the folder observability_solutions in plural. Also would be nice to keep it consistent across the code base:

AFAIU, Elastic speaks about having three solutions: Search, Security and Observability. To my mind observability_solution made more sense.

• Should we also have the Observability tests in a centralized folder too CoenWarmer/kibana@feat/re-org/x-pack/test?
• And Observability packages CoenWarmer/kibana@feat/re-org/packages?

Yes, I aim do that in a follow up PR.

[cauemarcondes]

How would that work with ESLint rule config?

Do we or will we have any Obs specific rules?

[CoenWarmer]

How would that work with ESLint rule config?

Do we or will we have any Obs specific rules?

We currently do, yes:

kibana/.eslintrc.js

Line 870 in a968a2e

* APM, UX and Observability overrides

[CoenWarmer]

@elasticmachine merge upstream

[kibana-ci]

💔 Build Failed

• Buildkite Build
• Commit: 2e67924
• Interpreting CI Failures
• Storybooks Preview

Failed CI Steps

• Profiling Cypress Tests #1
• Profiling Cypress Tests #1
• Profiling Cypress Tests #2
• Profiling Cypress Tests #2

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
apm	3.7MB	3.7MB	+29.0B
exploratoryView	203.4KB	203.4KB	+1.0B
infra	1.9MB	1.9MB	+8.0B
observabilityShared	36.3KB	36.3KB	+2.0B
synthetics	868.3KB	868.3KB	+2.0B
uptime	480.8KB	480.8KB	-3.0B
ux	168.9KB	168.9KB	+2.0B
total			+41.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
apm	36.6KB	36.6KB	+23.0B
exploratoryView	44.3KB	44.3KB	-4.0B
observabilityShared	48.0KB	48.0KB	+24.0B
total			+43.0B

History

• 💔 Build #178730 failed 54ee2ad
• 💔 Build #178725 failed 2142ce8ef7f0f000c666410cab5d3ca341a9def7
• 💔 Build #178515 failed 7af54c3590a0f3cc3e57ce23d42571d2c27928b9
• 💔 Build #178502 failed ccc8a7ced5f1bb711c73078d15f5f650e95ac098

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[CoenWarmer]

Closed, implemented by newer PRs.