Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IDM: Migrate core server-side core_app to package #144075

Merged

Conversation

TinaHeiligers
Copy link
Contributor

@TinaHeiligers TinaHeiligers commented Oct 27, 2022

fix #135865

Create package:
@kbn/core-apps-server-internal

Notes:

  • I couldn't find a public mock for the core_app service class, hence no corresponding mock package.
  • src/core/server/core_app contains assets included in the bundled routes. Following how I understood the inner workings of bundling and serving these assets, I tried moving the files to the package and updating the build scripts to account for the new paths. I also had to update the import path for the legacy_light_theme.css in canvas. That didn't work, so I had to duplicate the files and leave a subset of the assets in src/core.

@TinaHeiligers TinaHeiligers added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc release_note:skip Skip the PR/issue when compiling release notes backport:skip This commit does not require backporting v8.6.0 labels Oct 27, 2022
Copy link
Contributor Author

@TinaHeiligers TinaHeiligers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned in the PR description, I took the best guess at handling the assets, while leaving a copy of them in src/core/server/core_app.

SOURCE_FILES = glob(
[
"**/*.ts",
"src/**/*.css",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On a whim, I took the same approach as previously when handling code that includes stylesheets.

@@ -6,4 +6,4 @@
* Side Public License, v 1.
*/

export { CoreApp } from './core_app';
export { CoreAppsService } from './src';
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed the service class name to keep consistent with the browser-side service class counterpart.

import { fromRoot } from '@kbn/utils';
import UiSharedDepsNpm from '@kbn/ui-shared-deps-npm';
import * as UiSharedDepsSrc from '@kbn/ui-shared-deps-src';
import { distDir as UiSharedDepsSrcDistDir } from '@kbn/ui-shared-deps-src';
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

import * as ... doesn't work in packages. I took the approach of renaming the specific dependency.

@TinaHeiligers
Copy link
Contributor Author

@elasticmachine merge upstream


export { CoreAppsService } from './src';
export {
registerBundleRoutes,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are needed for the integration tests in src/core/server/integration_tests.
We can decide as a team how to handle the integration tests during the migration cleanup phase. The pending tooling changes should give us a bit more freedom in package structure and inteneral dependencies.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT: In similar cases for other packages, I added a comment to 'separate' the 'real' imports from the integration-test-only imports.

E.g:

// only used by integration tests
export { registerDeleteUnknownTypesRoute } from './src/routes/deprecations';
export { registerLegacyExportRoute } from './src/routes/legacy_import_export/export';
export { registerLegacyImportRoute } from './src/routes/legacy_import_export/import';
export { registerBulkCreateRoute } from './src/routes/bulk_create';
export { registerBulkGetRoute } from './src/routes/bulk_get';

SOURCE_FILES = glob(
[
"**/*.ts",
"src/**/*.css",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@elastic/kibana-operations is there a trick to serving the assets directly from the package so that we don't need to keep them in src/core?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WDYM by 'serving' here exactly?

To my knowledge, there are two usages of these files:

The correct one:

core.http.registerStaticDir('/ui/{path*}', Path.resolve(__dirname, './assets'));

which should work out of the box when the assets are moved in the package (right?)

And that scss import, that I didn't even knew about:

import '@kbn/core/server/core_app/assets/legacy_light_theme.css';

You're referring to the second one here, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, I'm referring to the second one.

export type {
InternalCoreAppsServiceRequestHandlerContext,
InternalCoreAppsServiceRouter,
} from './src';
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@elastic/kibana-operations how would we expose the assets from this package?

let coreApp: CoreApp;
let internalCorePreboot: ReturnType<typeof coreMock.createInternalPreboot>;
let coreApp: CoreAppsService;
let internalCorePreboot: ReturnType<typeof coreInternalLifecycleMock.createInternalPreboot>;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As of #141891, core's internal lifecycles are exposed in a package, so we can use those directly.

Copy link
Contributor Author

@TinaHeiligers TinaHeiligers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adds more self review comments

@TinaHeiligers
Copy link
Contributor Author

@elasticmachine merge upstream

@TinaHeiligers
Copy link
Contributor Author

@elasticmachine merge upstream

Copy link
Contributor Author

@TinaHeiligers TinaHeiligers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove location from dev script

@TinaHeiligers TinaHeiligers requested a review from spalger October 31, 2022 23:04
Copy link
Contributor

@pgayvallet pgayvallet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation looks good.

I'd like to have a better understanding of what the issue with the assets is (like, are we forced to duplicate all assets or not) before definitive approval:

SOURCE_FILES = glob(
[
"**/*.ts",
"src/**/*.css",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WDYM by 'serving' here exactly?

To my knowledge, there are two usages of these files:

The correct one:

core.http.registerStaticDir('/ui/{path*}', Path.resolve(__dirname, './assets'));

which should work out of the box when the assets are moved in the package (right?)

And that scss import, that I didn't even knew about:

import '@kbn/core/server/core_app/assets/legacy_light_theme.css';

You're referring to the second one here, right?


export { CoreAppsService } from './src';
export {
registerBundleRoutes,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT: In similar cases for other packages, I added a comment to 'separate' the 'real' imports from the integration-test-only imports.

E.g:

// only used by integration tests
export { registerDeleteUnknownTypesRoute } from './src/routes/deprecations';
export { registerLegacyExportRoute } from './src/routes/legacy_import_export/export';
export { registerLegacyImportRoute } from './src/routes/legacy_import_export/import';
export { registerBulkCreateRoute } from './src/routes/bulk_create';
export { registerBulkGetRoute } from './src/routes/bulk_get';

Comment on lines 1 to 5

Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(commenting here because GH doesn't allow me to do it on font/binary files): related to my first comment: What's the issue with the assets exactly? Are we forced to duplicate all of them (meaning keeping them all under src/core/server/core_app/assets too), or is the issue just about the scss import of the src/core/server/core_app/assets/legacy_light_theme.css file from

import '@kbn/core/server/core_app/assets/legacy_light_theme.css';

?

Because if that's the latest, I'd rather only keep the strict subset of required files in src/core/server/core_app/assets instead of duplicating them all.

Copy link
Contributor Author

@TinaHeiligers TinaHeiligers Nov 1, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, the only asset we need to keep for now is legacy_light_theme.css. We can follow up with changing the export at a later stage when we're forced to touch other teams' code.
Update, it turns out we need the favicons too.
Follow up WIP in #144375

@@ -13,15 +13,15 @@ import type { UiSettingsRequestHandlerContext } from '@kbn/core-ui-settings-serv
* Request handler context used by core's coreApp routes.
* @internal
*/
export interface InternalCoreAppRequestHandlerContext extends RequestHandlerContextBase {
export interface InternalCoreAppsServiceRequestHandlerContext extends RequestHandlerContextBase {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was internal, so the change wasn't strictly necessary, but 👍 for consistency.

@TinaHeiligers
Copy link
Contributor Author

TinaHeiligers commented Nov 1, 2022

Implementation looks good.

I'd like to have a better understanding of what the issue with the assets is (like, are we forced to duplicate all assets or not) before definitive approval:

On further investigation, the build scripts use the favicons in src/core/server/core_app (added here), and when I went through that PR I saw yet another reference to the favicons in their original location in core (security prompt_page).

For now, I'd prefer to keep the number of code-owners' reviews small while we finish our first pass at migrating core services to packages. we can clean all this up during the cleanup phase once we've had a chance to huddle with the @elastic/kibana-operations team.

I've began to attempt to change this in #144375

@TinaHeiligers TinaHeiligers force-pushed the kbn-135865-server-core-app-migration branch from 9f05131 to 7afc72b Compare November 1, 2022 19:09
@TinaHeiligers
Copy link
Contributor Author

@elasticmachine merge upstream

Copy link
Contributor

@pgayvallet pgayvallet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM given we have a follow-up created for my questions

@TinaHeiligers TinaHeiligers enabled auto-merge (squash) November 2, 2022 15:18
@TinaHeiligers
Copy link
Contributor Author

@elasticmachine merge upstream

Copy link
Member

@mistic mistic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes under operations team code owners LGTM

@kibana-ci
Copy link
Collaborator

💛 Build succeeded, but was flaky

Failed CI Steps

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
@kbn/core-apps-server-internal - 8 +8

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id before after diff
@kbn/core-apps-server-internal - 1 +1
Unknown metric groups

API count

id before after diff
@kbn/core-apps-server-internal - 8 +8

ESLint disabled in files

id before after diff
osquery 1 2 +1

ESLint disabled line counts

id before after diff
enterpriseSearch 19 21 +2
fleet 58 64 +6
osquery 103 108 +5
securitySolution 440 446 +6
total +19

Total ESLint disabled count

id before after diff
enterpriseSearch 20 22 +2
fleet 66 72 +6
osquery 104 110 +6
securitySolution 517 523 +6
total +20

History

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

@TinaHeiligers TinaHeiligers merged commit 0ba81e1 into elastic:main Nov 2, 2022
@TinaHeiligers TinaHeiligers deleted the kbn-135865-server-core-app-migration branch November 2, 2022 19:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting release_note:skip Skip the PR/issue when compiling release notes Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc v8.6.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Migrate core domain services to packages: Server-side core_app service
7 participants