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

CONSOLE-3853: Optimize module federation of PatternFly packages #13521

Merged

Conversation

vojtechszocs
Copy link
Contributor

Motivation

Console web application provides specific shared modules to its dynamic plugins.

Most of these shared modules are configured as follows:

  • only a single version of the module can be loaded at runtime (singleton: true)
  • plugins will not bundle their own fallback (i.e. build-time) version of the module (allowFallback: false)

While this configuration favors code consistency, it's not flexible enough for PatternFly packages.

Starting with 4.15 release, all PatternFly v4 shared modules are configured as singleton: false and allowFallback: true (#12983). This allows existing plugins using these PatternFly v4 shared modules to work as expected. At some point in future, these PatternFly v4 shared modules will be deprecated and eventually removed.

In order to share PatternFly v5+ modules in an optimal way, this PR implements the concept of shared dynamic modules.

Dynamic Modules

Some vendor packages may support dynamic modules to be used with webpack module federation.

Taking @patternfly/react-core package as an example, it includes a dist/dynamic directory containing package.json files that refer to specific modules of that package.

For example, all Alert component related code and types (including exports like Alert, AlertProps, AlertContext etc.) have a corresponding dynamic module at @patternfly/react-core/dist/dynamic/components/Alert/package.json

{
  "name": "@patternfly/react-core-alert-dynamic",
  "main": "../../../js/components/Alert/index.js", // => dist/js/components/Alert/index.js
  "module": "../../../esm/components/Alert/index.js", // => dist/esm/components/Alert/index.js
  "typings": "../../../esm/components/Alert/index.d.ts", // => dist/esm/components/Alert/index.d.ts
  "version": "5.1.1",
  "private": true
}

In the plugin code, this dynamic module can then be imported like so:

import { Alert, AlertProps, AlertContext } from '@patternfly/react-core/dist/dynamic/components/Alert';

Let's say the plugin also uses some other PatternFly components:

import { Wizard, WizardProps } from '@patternfly/react-core/dist/dynamic/components/Wizard';

Once we configure webpack module federation to treat each of these dynamic modules as shared modules like so:

// see packages/console-dynamic-plugin-sdk/src/webpack/ConsoleRemotePlugin.ts

new DynamicRemotePlugin({
  // ...
  sharedModules: {
    // ...
    '@patternfly/react-core/dist/dynamic/components/Alert': { version: '5.1.1', requiredVersion: '5.1.1' },
    '@patternfly/react-core/dist/dynamic/components/Wizard': { version: '5.1.1', requiredVersion: '5.1.1' },
  },
  // ...
});

this will effectively allow us to load the same Alert or Wizard dynamic module once or multiple times in different versions.

Example use case

  • Plugin A uses @patternfly/react-core 5.1.1 - using Alert and Wizard
    • Alert dynamic module [5.1.1] does not exist in shared scope ➡️ add to shared scope
    • Wizard dynamic module [5.1.1] does not exist in shared scope ➡️ add to shared scope
  • Plugin B uses @patternfly/react-core 5.1.1 - using only Wizard
    • Wizard dynamic module [5.1.1] exists in shared scope ➡️ reuse the one in shared scope
  • Plugin C uses @patternfly/react-core 5.2.0 - using only Alert
    • Alert dynamic module [5.2.0] does not exist in shared scope ➡️ add to shared scope

Dynamic module processing

This PR includes a parser (getDynamicModuleMap) that detects all dynamic modules of the given vendor package.

The default list of vendor packages for which dynamic modules should be processed is:

  • @patternfly/react-core
  • @patternfly/react-icons

This list can be customized via new ConsoleRemotePlugin option sharedDynamicModuleSettings.

ConsoleRemotePlugin has been modified to perform the following tasks:

  • ✔️ automatically detect all dynamic modules and register them with webpack as shared modules
  • ✔️ automatically transform imports within the plugin code to utilize dynamic modules whenever possible

Impact on existing plugins

This PR attempts to be as backwards compatible as possible and provide reasonable defaults for all dynamic plugins.

Here is the list of checks and minor changes that plugins should address:

  • @openshift-console/dynamic-plugin-sdk-webpack now has a peer dependency "typescript": ">=4.5.5"
    • ❗ make sure your project has a typescript (dev) dependency that matches the above range
    • 📝 this is due to webpack dynamicModuleImportLoader using TypeScript compiler API to transform code
  • make sure your project has explicit @patternfly/react-core and @patternfly/react-icons (dev) dependencies
    • 📝 otherwise, you may get webpack warnings about being unable to detect required version of dynamic modules
  • avoid non-index imports for @patternfly/react-core and @patternfly/react-icons packages
    • 📝 webpack dynamicModuleImportLoader will warn you about any non-index imports detected in your code
// do _not_ do this:
import { MonitoringIcon } from '@patternfly/react-icons/dist/esm/icons/monitoring-icon';
// instead, do this:
import { MonitoringIcon } from '@patternfly/react-icons';

Smoke test verification

  • dynamic demo plugin can be built without any errors or warnings
  • dynamic demo plugin loads and works in Console as before
  • in development build of Console, inspect webpackSharedScope object

@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Jan 18, 2024
@openshift-ci-robot
Copy link
Contributor

openshift-ci-robot commented Jan 18, 2024

@vojtechszocs: This pull request references CONSOLE-3853 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.16.0" version, but no target version was set.

In response to this:

Motivation

Console web application provides specific shared modules to its dynamic plugins.

Most of these shared modules are configured as follows:

  • only a single version of the module can be loaded at runtime (singleton: true)
  • plugins will not bundle their own fallback (i.e. build-time) version of the module (allowFallback: false)

While this configuration favors code consistency, it's not flexible enough for PatternFly packages.

Starting with 4.15 release, all PatternFly v4 shared modules are configured as singleton: false and allowFallback: true (#12983). This allows existing plugins using these PatternFly v4 shared modules to work as expected. At some point in future, these PatternFly v4 shared modules will be deprecated and eventually removed.

In order to share PatternFly v5+ modules in an optimal way, this PR implements the concept of shared dynamic modules.

Dynamic Modules

Some vendor packages may support dynamic modules to be used with webpack module federation.

Taking @patternfly/react-core package as an example, it includes a dist/dynamic directory containing package.json files that refer to specific modules of that package.

For example, all Alert component related code and types (including exports like Alert, AlertProps, AlertContext etc.) have a corresponding dynamic module at @patternfly/react-core/dist/dynamic/components/Alert/package.json

{
 "name": "@patternfly/react-core-alert-dynamic",
 "main": "../../../js/components/Alert/index.js", // => dist/js/components/Alert/index.js
 "module": "../../../esm/components/Alert/index.js", // => dist/esm/components/Alert/index.js
 "typings": "../../../esm/components/Alert/index.d.ts", // => dist/esm/components/Alert/index.d.ts
 "version": "5.1.1",
 "private": true
}

In the plugin code, this dynamic module can then be imported like so:

import { Alert, AlertProps, AlertContext } from '@patternfly/react-core/dist/dynamic/components/Alert';

Let's say the plugin also uses some other PatternFly components:

import { Wizard, WizardProps } from '@patternfly/react-core/dist/dynamic/components/Wizard';

Once we configure webpack module federation to treat each of these dynamic modules as shared modules like so:

// see packages/console-dynamic-plugin-sdk/src/webpack/ConsoleRemotePlugin.ts

new DynamicRemotePlugin({
 // ...
 sharedModules: {
   // ...
   '@patternfly/react-core/dist/dynamic/components/Alert': { version: '5.1.1', requiredVersion: '5.1.1' },
   '@patternfly/react-core/dist/dynamic/components/Wizard': { version: '5.1.1', requiredVersion: '5.1.1' },
 },
 // ...
});

this will effectively allow us to load the same Alert or Wizard dynamic module once or multiple times in different versions.

Example use case

  • Plugin A uses @patternfly/react-core 5.1.1 - using Alert and Wizard
  • Alert dynamic module [5.1.1] does not exist in shared scope ➡️ add to shared scope
  • Wizard dynamic module [5.1.1] does not exist in shared scope ➡️ add to shared scope
  • Plugin B uses @patternfly/react-core 5.1.1 - using only Wizard
  • Wizard dynamic module [5.1.1] exists in shared scope ➡️ reuse the one in shared scope
  • Plugin C uses @patternfly/react-core 5.2.0 - using only Alert
  • Alert dynamic module [5.2.0] does not exist in shared scope ➡️ add to shared scope

Dynamic module processing

This PR includes a parser (getDynamicModuleMap) that detects all dynamic modules of the given vendor package.

The default list of vendor packages for which dynamic modules should be processed is:

  • @patternfly/react-core
  • @patternfly/react-icons

This list can be customized via new ConsoleRemotePlugin option sharedDynamicModuleSettings.

ConsoleRemotePlugin has been modified to perform the following tasks:

  • ✔️ automatically detect all dynamic modules and register them with webpack as shared modules
  • ✔️ automatically transform imports within the plugin code to utilize dynamic modules whenever possible

Impact on existing plugins

This PR attempts to be as backwards compatible as possible and provide reasonable defaults for all dynamic plugins.

Here is the list of checks and minor changes that plugins should address:

  • @openshift-console/dynamic-plugin-sdk-webpack now has a peer dependency "typescript": ">=4.5.5"
  • ❗ make sure your project has a typescript (dev) dependency that matches the above range
  • 📝 this is due to webpack dynamicModuleImportLoader using TypeScript compiler API to transform code
  • make sure your project has explicit @patternfly/react-core and @patternfly/react-icons (dev) dependencies
  • 📝 otherwise, you may get webpack warnings about being unable to detect required version of dynamic modules
  • avoid non-index imports for @patternfly/react-core and @patternfly/react-icons packages
  • 📝 webpack dynamicModuleImportLoader will warn you about any non-index imports detected in your code
// do _not_ do this:
import { MonitoringIcon } from '@patternfly/react-icons/dist/esm/icons/monitoring-icon';
// instead, do this:
import { MonitoringIcon } from '@patternfly/react-icons';

Smoke test verification

  • dynamic demo plugin can be built without any errors or warnings
  • dynamic demo plugin loads and works in Console as before
  • in development build of Console, inspect webpackSharedScope object

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci openshift-ci bot added the component/sdk Related to console-plugin-sdk label Jan 18, 2024
);

if (!modifiedModules.includes(moduleRequest) && transformImports(moduleRequest)) {
normalModule.loaders.push({
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is where our custom loader gets registered for modules that match the transformImports filter.

webpack loaders are applied in reverse order, so the last one runs first.

This code was inspired by https://github.com/artembatura/modify-source-webpack-plugin

@vojtechszocs
Copy link
Contributor Author

/retest

Copy link
Member

@spadgett spadgett left a comment

Choose a reason for hiding this comment

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

Nice work on this 👍 No major concerns from me. I'll give @jhadvig and others a chance to review.

/approve

import { MonitoringIcon } from '@patternfly/react-icons/dist/esm/icons/monitoring-icon';
import { MonitoringIcon } from '@patternfly/react-icons';
Copy link
Member

Choose a reason for hiding this comment

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

We'll make sure we document the recommended way to do these imports.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@spadgett @jhadvig The dynamic plugin README is already quite big.

I think it makes sense to add a separate Markdown doc to document Console plugin shared modules, including PatternFly dynamic modules. What do you think?

Copy link
Member

Choose a reason for hiding this comment

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

So I think it would be best to keep it tin the dynamic plugin README, even if its will make it bigger.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK, will update the README.

const dynamicModulePathToPkgDir = glob
.sync(`${basePath}/dist/dynamic/**/package.json`)
.reduce<Record<string, string>>((acc, pkgFile) => {
// eslint-disable-next-line
Copy link
Member

Choose a reason for hiding this comment

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

nitpick: better to only disable the eslint rule we need

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@spadgett The require call (line below) actually triggers multiple ESLint errors:

  72:19  error  Calls to require() should use string literals   import/no-dynamic-require
  72:19  error  Unexpected require()                            global-require
  72:19  error  A `require()` style import is forbidden         @typescript-eslint/no-require-imports
  72:19  error  Require statement not part of import statement  @typescript-eslint/no-var-requires

so I didn't specify the rule names explicitly. Such require calls always tend to trigger a lot of ESLint errors.

Is it OK to leave it like so for simplicity?

We do this also in some other parts of the codebase, e.g. packages/console-dynamic-plugin-sdk/src/runtime/plugin-manifest.ts

Copy link
Member

Choose a reason for hiding this comment

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

+1 leaving as is

Copy link
Member

Choose a reason for hiding this comment

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

Thank you for adding the tests 👍

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 19, 2024
@rhamilto
Copy link
Member

/lgtm

QE Approver:
/assign @yapei
Docs Approver:
/assign @opayne1
PX Approver:
/assign @RickJWagner

@RickJWagner
Copy link

/label px-approved

@RickJWagner RickJWagner removed their assignment Jan 22, 2024
Copy link
Member

@jhadvig jhadvig left a comment

Choose a reason for hiding this comment

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

🤯 🤯 🤯
Awesome work @vojtechszocs Looking forward for the demo 🙌
/lgtm

import { MonitoringIcon } from '@patternfly/react-icons/dist/esm/icons/monitoring-icon';
import { MonitoringIcon } from '@patternfly/react-icons';
Copy link
Member

Choose a reason for hiding this comment

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

So I think it would be best to keep it tin the dynamic plugin README, even if its will make it bigger.

@jhadvig
Copy link
Member

jhadvig commented Jan 22, 2024

/retest

@opayne1
Copy link
Contributor

opayne1 commented Jan 22, 2024

/label docs-approved

@openshift-ci openshift-ci bot added the docs-approved Signifies that Docs has signed off on this PR label Jan 22, 2024
@jhadvig jhadvig added lgtm Indicates that a PR is ready to be merged. px-approved Signifies that Product Support has signed off on this PR labels Jan 23, 2024
@jhadvig
Copy link
Member

jhadvig commented Jan 23, 2024

adding labels manually since they are not picked up by the bot

@jhadvig
Copy link
Member

jhadvig commented Jan 24, 2024

/retest

@openshift-ci openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Jan 29, 2024
@@ -11,5 +11,12 @@
"skipLibCheck": true,
"lib": ["dom", "es7", "es2017.string"]
},
"include": ["src"]
"include": ["src"],
"ts-node": {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This makes debugging the Console webpack code (triggered via demo plugin webpack build) much easier, paired with the following VS Code launch config:

{
  "name": "Example",
  "type": "node",
  "request": "launch",
  "runtimeExecutable": "node",
  "runtimeArgs": ["--nolazy", "-r", "ts-node/register/transpile-only"],
  "args": ["node_modules/.bin/webpack"],
  "cwd": "${workspaceRoot}",
  "internalConsoleOptions": "openOnSessionStart",
  "skipFiles": ["<node_internals>/**"]
}

Copy link
Member

@jhadvig jhadvig left a comment

Choose a reason for hiding this comment

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

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jan 30, 2024
Copy link
Contributor

openshift-ci bot commented Jan 30, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jhadvig, rhamilto, spadgett, vojtechszocs

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:
  • OWNERS [jhadvig,rhamilto,spadgett]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@XiyunZhao
Copy link

The dynamic demo plugin could be loaded without any issue, all plugin fictional is work as normal, no new CSS issue found
For the local development, the plugin can be built without any errors, and the information of 'webpackSharedScope' object is correct.
/label qe-approved

@openshift-ci openshift-ci bot added the qe-approved Signifies that QE has signed off on this PR label Jan 30, 2024
@openshift-ci-robot
Copy link
Contributor

openshift-ci-robot commented Jan 30, 2024

@vojtechszocs: This pull request references CONSOLE-3853 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.16.0" version, but no target version was set.

In response to this:

Motivation

Console web application provides specific shared modules to its dynamic plugins.

Most of these shared modules are configured as follows:

  • only a single version of the module can be loaded at runtime (singleton: true)
  • plugins will not bundle their own fallback (i.e. build-time) version of the module (allowFallback: false)

While this configuration favors code consistency, it's not flexible enough for PatternFly packages.

Starting with 4.15 release, all PatternFly v4 shared modules are configured as singleton: false and allowFallback: true (#12983). This allows existing plugins using these PatternFly v4 shared modules to work as expected. At some point in future, these PatternFly v4 shared modules will be deprecated and eventually removed.

In order to share PatternFly v5+ modules in an optimal way, this PR implements the concept of shared dynamic modules.

Dynamic Modules

Some vendor packages may support dynamic modules to be used with webpack module federation.

Taking @patternfly/react-core package as an example, it includes a dist/dynamic directory containing package.json files that refer to specific modules of that package.

For example, all Alert component related code and types (including exports like Alert, AlertProps, AlertContext etc.) have a corresponding dynamic module at @patternfly/react-core/dist/dynamic/components/Alert/package.json

{
 "name": "@patternfly/react-core-alert-dynamic",
 "main": "../../../js/components/Alert/index.js", // => dist/js/components/Alert/index.js
 "module": "../../../esm/components/Alert/index.js", // => dist/esm/components/Alert/index.js
 "typings": "../../../esm/components/Alert/index.d.ts", // => dist/esm/components/Alert/index.d.ts
 "version": "5.1.1",
 "private": true
}

In the plugin code, this dynamic module can then be imported like so:

import { Alert, AlertProps, AlertContext } from '@patternfly/react-core/dist/dynamic/components/Alert';

Let's say the plugin also uses some other PatternFly components:

import { Wizard, WizardProps } from '@patternfly/react-core/dist/dynamic/components/Wizard';

Once we configure webpack module federation to treat each of these dynamic modules as shared modules like so:

// see packages/console-dynamic-plugin-sdk/src/webpack/ConsoleRemotePlugin.ts

new DynamicRemotePlugin({
 // ...
 sharedModules: {
   // ...
   '@patternfly/react-core/dist/dynamic/components/Alert': { version: '5.1.1', requiredVersion: '5.1.1' },
   '@patternfly/react-core/dist/dynamic/components/Wizard': { version: '5.1.1', requiredVersion: '5.1.1' },
 },
 // ...
});

this will effectively allow us to load the same Alert or Wizard dynamic module once or multiple times in different versions.

Example use case

  • Plugin A uses @patternfly/react-core 5.1.1 - using Alert and Wizard
  • Alert dynamic module [5.1.1] does not exist in shared scope ➡️ add to shared scope
  • Wizard dynamic module [5.1.1] does not exist in shared scope ➡️ add to shared scope
  • Plugin B uses @patternfly/react-core 5.1.1 - using only Wizard
  • Wizard dynamic module [5.1.1] exists in shared scope ➡️ reuse the one in shared scope
  • Plugin C uses @patternfly/react-core 5.2.0 - using only Alert
  • Alert dynamic module [5.2.0] does not exist in shared scope ➡️ add to shared scope

Dynamic module processing

This PR includes a parser (getDynamicModuleMap) that detects all dynamic modules of the given vendor package.

The default list of vendor packages for which dynamic modules should be processed is:

  • @patternfly/react-core
  • @patternfly/react-icons

This list can be customized via new ConsoleRemotePlugin option sharedDynamicModuleSettings.

ConsoleRemotePlugin has been modified to perform the following tasks:

  • ✔️ automatically detect all dynamic modules and register them with webpack as shared modules
  • ✔️ automatically transform imports within the plugin code to utilize dynamic modules whenever possible

Impact on existing plugins

This PR attempts to be as backwards compatible as possible and provide reasonable defaults for all dynamic plugins.

Here is the list of checks and minor changes that plugins should address:

  • @openshift-console/dynamic-plugin-sdk-webpack now has a peer dependency "typescript": ">=4.5.5"
  • ❗ make sure your project has a typescript (dev) dependency that matches the above range
  • 📝 this is due to webpack dynamicModuleImportLoader using TypeScript compiler API to transform code
  • make sure your project has explicit @patternfly/react-core and @patternfly/react-icons (dev) dependencies
  • 📝 otherwise, you may get webpack warnings about being unable to detect required version of dynamic modules
  • avoid non-index imports for @patternfly/react-core and @patternfly/react-icons packages
  • 📝 webpack dynamicModuleImportLoader will warn you about any non-index imports detected in your code
// do _not_ do this:
import { MonitoringIcon } from '@patternfly/react-icons/dist/esm/icons/monitoring-icon';
// instead, do this:
import { MonitoringIcon } from '@patternfly/react-icons';

Smoke test verification

  • dynamic demo plugin can be built without any errors or warnings
  • dynamic demo plugin loads and works in Console as before
  • in development build of Console, inspect webpackSharedScope object

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@vojtechszocs
Copy link
Contributor Author

vojtechszocs commented Jan 30, 2024

This PR addresses the following item of CONSOLE-3883 (Improve Console dynamic plugin documentation)

improve docs on shared modules (CONSOLE-3328)

@jhadvig
Copy link
Member

jhadvig commented Jan 31, 2024

/label acknowledge-critical-fixes-only

@openshift-ci openshift-ci bot added the acknowledge-critical-fixes-only Indicates if the issuer of the label is OK with the policy. label Jan 31, 2024
@openshift-ci-robot
Copy link
Contributor

/retest-required

Remaining retests: 0 against base HEAD 4f8fa7b and 2 for PR HEAD 6c9b2ea in total

@openshift-ci-robot
Copy link
Contributor

/retest-required

Remaining retests: 0 against base HEAD aa09f42 and 1 for PR HEAD 6c9b2ea in total

@openshift-ci-robot
Copy link
Contributor

/retest-required

Remaining retests: 0 against base HEAD 6935c3f and 0 for PR HEAD 6c9b2ea in total

@openshift-ci-robot
Copy link
Contributor

/hold

Revision 6c9b2ea was retested 3 times: holding

@openshift-ci openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 1, 2024
@rhamilto
Copy link
Member

rhamilto commented Feb 1, 2024

/retest

@jhadvig
Copy link
Member

jhadvig commented Feb 1, 2024

/cherry-pick release-4.15

@openshift-cherrypick-robot

@jhadvig: once the present PR merges, I will cherry-pick it on top of release-4.15 in a new PR and assign it to you.

In response to this:

/cherry-pick release-4.15

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@vojtechszocs
Copy link
Contributor Author

/hold cancel

@openshift-ci openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 1, 2024
@openshift-ci-robot
Copy link
Contributor

/retest-required

Remaining retests: 0 against base HEAD 6935c3f and 2 for PR HEAD 6c9b2ea in total

@vojtechszocs
Copy link
Contributor Author

/retest

@openshift-ci-robot
Copy link
Contributor

/retest-required

Remaining retests: 0 against base HEAD 97b8914 and 1 for PR HEAD 6c9b2ea in total

@jhadvig
Copy link
Member

jhadvig commented Feb 2, 2024

/retest

Copy link
Contributor

openshift-ci bot commented Feb 2, 2024

@vojtechszocs: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@openshift-merge-bot openshift-merge-bot bot merged commit 74c31e3 into openshift:master Feb 2, 2024
6 checks passed
@openshift-cherrypick-robot

@jhadvig: #13521 failed to apply on top of branch "release-4.15":

Applying: Optimize module federation of PatternFly packages
Using index info to reconstruct a base tree...
M	dynamic-demo-plugin/yarn.lock
M	frontend/packages/console-dynamic-plugin-sdk/scripts/package-definitions.ts
M	frontend/packages/console-dynamic-plugin-sdk/src/webpack/ConsoleRemotePlugin.ts
Falling back to patching base and 3-way merge...
Auto-merging frontend/packages/console-dynamic-plugin-sdk/src/webpack/ConsoleRemotePlugin.ts
CONFLICT (content): Merge conflict in frontend/packages/console-dynamic-plugin-sdk/src/webpack/ConsoleRemotePlugin.ts
Auto-merging frontend/packages/console-dynamic-plugin-sdk/scripts/package-definitions.ts
Auto-merging dynamic-demo-plugin/yarn.lock
Removing dynamic-demo-plugin/.gitignore
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 Optimize module federation of PatternFly packages
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

In response to this:

/cherry-pick release-4.15

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-bot
Copy link
Contributor

[ART PR BUILD NOTIFIER]

This PR has been included in build openshift-enterprise-console-container-v4.16.0-202402021641.p0.g74c31e3.assembly.stream for distgit openshift-enterprise-console.
All builds following this will include this PR.

kyoto added a commit to kyoto/lightspeed-console that referenced this pull request Feb 5, 2024
Since openshift/console#13521 merged, plugins
are expected to have an explicit @patternfly/react-icons dependency.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
acknowledge-critical-fixes-only Indicates if the issuer of the label is OK with the policy. approved Indicates a PR has been approved by an approver from all required OWNERS files. component/sdk Related to console-plugin-sdk docs-approved Signifies that Docs has signed off on this PR jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. lgtm Indicates that a PR is ready to be merged. px-approved Signifies that Product Support has signed off on this PR qe-approved Signifies that QE has signed off on this PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet