OU-666: fix overriding webpack compilation results

[PeterYurkovich]

When building a plugin, webpack will typically chose to name the javascript entry file as plugin-entry.min.js, however it is valid under our build configurations for it to create a plugin entry file with any name, such as plugin-entry.656f1eb7b0b32d1aa0fa.min.js.

When webpack creates a plugin entry file with a different name, it will append the following information into the plugin-manifest.json file that it generates:

{
  "name": "logging-view-plugin",
  ...
  "registrationMethod": "callback",
  "baseURL": "/api/plugins/logging-view-plugin/",
  "loadScripts": ["plugin-entry.656f1eb7b0b32d1aa0fa.min.js"],
  "buildHash": "656f1eb7b0b32d1aa0fab058998b5b9f"
}

In order to inject the appropriate extension points while having  the console-extensions.json file keep all of the extension points for simple development, a separate hardcoded plugin-manifest.json file is used as the base to add the extensions onto.

However, this will then lose the information created by the webpack build in the generated plugin-manifest.json leading to the plugin being unable to load it's entrypoint and failing to load.

---

This PR looks to update the updating of the plugin-manifest.json file to instead use the generated file as the base, then performing a clear-extensions.patch.json action (similar to the monitoring-plugin) which injects the default extension points and allows for the remaining features to inject their extension points on top of it.

[openshift-ci-robot]

@PeterYurkovich: This pull request references OU-666 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 bug to target the "4.19.0" version, but no target version was set.

In response to this:

When building a plugin, webpack will typically chose to name the javascript entry file as plugin-entry.min.js, however it is valid under our build configurations for it to create a plugin entry file with any name, such as plugin-entry.656f1eb7b0b32d1aa0fa.min.js.

When webpack creates a plugin entry file with a different name, it will append the following information into the plugin-manifest.json file that it generates:

{
  "name": "logging-view-plugin",
  ...
  "registrationMethod": "callback",
  "baseURL": "/api/plugins/logging-view-plugin/",
  "loadScripts": ["plugin-entry.656f1eb7b0b32d1aa0fa.min.js"],
  "buildHash": "656f1eb7b0b32d1aa0fab058998b5b9f"
}

In order to inject the appropriate extension points while having  the console-extensions.json file keep all of the extension points for simple development, a separate hardcoded plugin-manifest.json file is used as the base to add the extensions onto.

However, this will then lose the information created by the webpack build in the generated plugin-manifest.json leading to the plugin being unable to load it's entrypoint and failing to load.

---

This PR looks to update the updating of the plugin-manifest.json file to instead use the generated file as the base, then performing a clear-extensions.patch.json action (similar to the monitoring-plugin) which injects the default extension points and allows for the remaining features to inject their extension points on top of it.

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-robot]

@PeterYurkovich: This pull request references OU-666 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 bug to target the "4.19.0" version, but no target version was set.

In response to this:

When building a plugin, webpack will typically chose to name the javascript entry file as plugin-entry.min.js, however it is valid under our build configurations for it to create a plugin entry file with any name, such as plugin-entry.656f1eb7b0b32d1aa0fa.min.js.

When webpack creates a plugin entry file with a different name, it will append the following information into the plugin-manifest.json file that it generates:

{
  "name": "logging-view-plugin",
  ...
  "registrationMethod": "callback",
  "baseURL": "/api/plugins/logging-view-plugin/",
  "loadScripts": ["plugin-entry.656f1eb7b0b32d1aa0fa.min.js"],
  "buildHash": "656f1eb7b0b32d1aa0fab058998b5b9f"
}

In order to inject the appropriate extension points while having  the console-extensions.json file keep all of the extension points for simple development, a separate hardcoded plugin-manifest.json file is used as the base to add the extensions onto.

However, this will then lose the information created by the webpack build in the generated plugin-manifest.json leading to the plugin being unable to load it's entrypoint and failing to load.

---

This PR looks to update the updating of the plugin-manifest.json file to instead use the generated file as the base, then performing a clear-extensions.patch.json action (similar to the monitoring-plugin) which injects the default extension points and allows for the remaining features to inject their extension points on top of it.

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.

[jgbernalp]

/lgtm
/hold
for QE

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jgbernalp, PeterYurkovich

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 [PeterYurkovich,jgbernalp]

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

[PeterYurkovich]

/cherry-pick release-6.1

[openshift-cherrypick-robot]

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

In response to this:

/cherry-pick release-6.1

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-sigs/prow repository.

[etmurasaki]

manual / exploratory testing performed:
https://docs.google.com/document/d/1aNX97kZ9s9lS9OpEsMjQpXMyIJY1c2K9lZyEvQjbUjM/edit?usp=sharing
@jgbernalp and @PeterYurkovich, please take a look. It seems to be ok.

[jgbernalp]

/unhold

[jgbernalp]

/label ux-approved
/label qe-approved

[openshift-ci]

@jgbernalp: The label(s) /label ux-approved cannot be applied. These labels are supported: acknowledge-critical-fixes-only, platform/aws, platform/azure, platform/baremetal, platform/google, platform/libvirt, platform/openstack, ga, tide/merge-method-merge, tide/merge-method-rebase, tide/merge-method-squash, px-approved, docs-approved, qe-approved, no-qe, downstream-change-needed, rebase/manual, cluster-config-api-changed, approved, backport-risk-assessed, bugzilla/valid-bug, cherry-pick-approved, jira/valid-bug, staff-eng-approved. Is this label configured under labels -> additional_labels or labels -> restricted_labels in plugin.yaml?

In response to this:

/label ux-approved
/label qe-approved

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-sigs/prow repository.

[openshift-ci-robot]

@PeterYurkovich: This pull request references OU-666 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 bug to target the "4.19.0" version, but no target version was set.

In response to this:

When building a plugin, webpack will typically chose to name the javascript entry file as plugin-entry.min.js, however it is valid under our build configurations for it to create a plugin entry file with any name, such as plugin-entry.656f1eb7b0b32d1aa0fa.min.js.

When webpack creates a plugin entry file with a different name, it will append the following information into the plugin-manifest.json file that it generates:

{
  "name": "logging-view-plugin",
  ...
  "registrationMethod": "callback",
  "baseURL": "/api/plugins/logging-view-plugin/",
  "loadScripts": ["plugin-entry.656f1eb7b0b32d1aa0fa.min.js"],
  "buildHash": "656f1eb7b0b32d1aa0fab058998b5b9f"
}

In order to inject the appropriate extension points while having  the console-extensions.json file keep all of the extension points for simple development, a separate hardcoded plugin-manifest.json file is used as the base to add the extensions onto.

However, this will then lose the information created by the webpack build in the generated plugin-manifest.json leading to the plugin being unable to load it's entrypoint and failing to load.

---

This PR looks to update the updating of the plugin-manifest.json file to instead use the generated file as the base, then performing a clear-extensions.patch.json action (similar to the monitoring-plugin) which injects the default extension points and allows for the remaining features to inject their extension points on top of it.

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.

[jgbernalp]

/label ux-approved

[openshift-ci]

@jgbernalp: The label(s) ux-approved cannot be applied, because the repository doesn't have them.

In response to this:

/label ux-approved

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-sigs/prow repository.

[openshift-ci]

@PeterYurkovich: 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-sigs/prow repository. I understand the commands that are listed here.

[openshift-cherrypick-robot]

@PeterYurkovich: new pull request created: #261

In response to this:

/cherry-pick release-6.1

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-sigs/prow repository.