Loading...

XML

Word

Printable

Type: Bug
Resolution: Done
Priority: Critical
Fix Version/s: 1.7.0
Affects Version/s: 1.7.0
Component/s: Documentation, Operator
Labels:
None

Story Points:
1
Blocked:
False
Blocked Reason:

Hide

None

Show
None
Ready:
False
Release Note Text:

Hide
= Using an optional Secret named `dynamic-plugins-npmrc` to configure a custom NPM registry in the Operator is removed

Previously, the Operator could automatically detect and mount an optional Secret named `dynamic-plugins-npmrc` to configure a custom npm registry.

With this update, you can do any of the following workarounds:

* Modify the `default-config/secret-files.yaml` key in the default configuration of the Operator (`rhdh-default-config` ConfigMap in the `rhdh-operator` namespace) to include custom `.npmrc` content.
* In your {product-custom-resource-type} custom resource (CR), complete the following steps:
.. Create a new Secret containing the custom `.npmrc` content.
.. Mount the Secret to the `install-dynamic-plugins` initContainer.
.. Set the `NPM_CONFIG_USERCONFIG` environment variable to reference to the mounted `.npmrc` file in the `spec.deployment.patch` section.
+
.Example of a Secret containing the .npmrc file
[source,yaml,subs='+attributes,+quotes']
----
apiVersion: v1
kind: Secret
metadata:
  name: dynamic-plugins-npmrc
type: Opaque
stringData:
  .npmrc: |
    @my-company:registry=https://my-company.example.com
    //<registry-url>:_authToken=<auth-token>
---
apiVersion: rhdh.redhat.com/v1alpha3
kind: Backstage
metadata:
  name: my-rhdh
spec:
  application:
    dynamicPluginsConfigMapName: my-dynamic-plugins-rhdh
  # --- BEGIN WORKAROUND: Ensure you have the volumes, volume mounts and NPM_CONFIG_USERCONFIG env var listed below
  deployment:
    patch:
      spec:
        template:
          spec:
            initContainers:
              - name: install-dynamic-plugins
                volumeMounts:
                  - mountPath: /opt/app-root/src/.my-dynamic-plugins-npmrc.dynamic-plugins
                    name: my-dynamic-plugins-npmrc
                env:
                  - name:
                  - name: NPM_CONFIG_USERCONFIG
                    # path before .npmrc should be the same as in the mountPath above
                    # file name .npmrc should be the same as key in the dynamic-plugins-npmrc secret above
                    value: /opt/app-root/src/.my-dynamic-plugins-npmrc.dynamic-plugins/.npmrc
            volumes:
              - name: my-dynamic-plugins-npmrc
                secret:
                  secretName: dynamic-plugins-npmrc
  # --- END WORKAROUND
----

Show
= Using an optional Secret named `dynamic-plugins-npmrc` to configure a custom NPM registry in the Operator is removed Previously, the Operator could automatically detect and mount an optional Secret named `dynamic-plugins-npmrc` to configure a custom npm registry. With this update, you can do any of the following workarounds: * Modify the `default-config/secret-files.yaml` key in the default configuration of the Operator (`rhdh-default-config` ConfigMap in the `rhdh-operator` namespace) to include custom `.npmrc` content. * In your {product-custom-resource-type} custom resource (CR), complete the following steps: .. Create a new Secret containing the custom `.npmrc` content. .. Mount the Secret to the `install-dynamic-plugins` initContainer. .. Set the `NPM_CONFIG_USERCONFIG` environment variable to reference to the mounted `.npmrc` file in the `spec.deployment.patch` section. + .Example of a Secret containing the .npmrc file [source,yaml,subs='+attributes,+quotes'] ---- apiVersion: v1 kind: Secret metadata:   name: dynamic-plugins-npmrc type: Opaque stringData:   .npmrc: |     @my-company:registry= https://my-company.example.com     //<registry-url>:_authToken=<auth-token> --- apiVersion: rhdh.redhat.com/v1alpha3 kind: Backstage metadata:   name: my-rhdh spec:   application:     dynamicPluginsConfigMapName: my-dynamic-plugins-rhdh   # --- BEGIN WORKAROUND: Ensure you have the volumes, volume mounts and NPM_CONFIG_USERCONFIG env var listed below   deployment:     patch:       spec:         template:           spec:             initContainers:               - name: install-dynamic-plugins                 volumeMounts:                   - mountPath: /opt/app-root/src/.my-dynamic-plugins-npmrc.dynamic-plugins                     name: my-dynamic-plugins-npmrc                 env:                   - name:                   - name: NPM_CONFIG_USERCONFIG                     # path before .npmrc should be the same as in the mountPath above                     # file name .npmrc should be the same as key in the dynamic-plugins-npmrc secret above                     value: /opt/app-root/src/.my-dynamic-plugins-npmrc.dynamic-plugins/.npmrc             volumes:               - name: my-dynamic-plugins-npmrc                 secret:                   secretName: dynamic-plugins-npmrc   # --- END WORKAROUND ----
Release Note Type:
Removed Functionality
Release Note Status:
Done
Git Pull Request:
https://github.com/redhat-developer/red-hat-developers-documentation-rhdh/pull/1346
Intelligence Requested:
Market:

SFDC Cases Links:
SFDC Cases Open:
SFDC Cases Counter:

Description of problem:

As reported in RHDHSUPP-263 and RHDHSUPP-263, the ability to have a manually-created Secret named dynamic-plugins-npmrc automatically mounted by the Operator so as to load dynamic plugins from custom NPM registries appears to be broken in 1.7.0

That said, it seems there is no mention of this ability in the current Release Notes (1.6, 1.7); only the Helm Chart is mentioned.

Prerequisites (if any, like setup, operators/versions):

This happens in the following cases:

Migration from Operator 1.6.4 (where this worked) to 1.7.0.
First install of the 1.7.0 version of the Operator

Steps to Reproduce

Install the RHDH Operator 1.7.0

Create a dynamic-plugins-npmrc Secret in your namespace, like so:

apiVersion: v1
kind: Secret
metadata: 
  name: dynamic-plugins-npmrc
type: Opaque
stringData: 
  .npmrc: |
    @my-company:registry=https://my-company.example.com
    //<registry-url>:_authToken=<auth-token>

Create a dynamic plugins ConfigMap that should try to install a plugin in the registry above. This is just an example with a fake plugin; I just wanted to check if the init container was actually loading the npmrc Secret above.

apiVersion: v1
kind: ConfigMap
metadata: 
  name: my-dynamic-plugins-rhdh
data: 
  dynamic-plugins.yaml: |
    includes: 
      - dynamic-plugins.default.yaml
    plugins: 
      - package: "@my-company/my-fake-dynamic-plugins-pkg@1.2.3"
        integrity: sha512-7VOe+XGTUzrdO/av0DNHbydOjB3Lo+XdCs6fj3JVODLP7Ypd3GXHf/nssYxG5ZYC9F1t9MNeguE2bZOB6ckqTA==
        disabled: false

Now create a Backstage CR (in the same namespace as the secret and ConfigMap above):

apiVersion: rhdh.redhat.com/v1alpha3
kind: Backstage
metadata: 
  name: my-rhdh
spec: 
  application: 
    dynamicPluginsConfigMapName: my-dynamic-plugins-rhdh

Watch the init container logs

Actual results:

The behavior in 1.6 is that the init container tries to load the fake plugin from https://my-company.example.com (the error below is expected):

======= Installing dynamic plugin @my-company/my-fake-dynamic-plugins-pkg@1.2.3
[...]
npm error network request to https://my-company.example.com/@my-company%2fmy-fake-dynamic-plugins-pkg failed, reason: getaddrinfo ENOTFOUND my-company.example.com
[...]

In 1.7.0, it is trying to load it from registry.npmjs.org, which is the default registry.

======= Installing dynamic plugin @my-company/my-fake-dynamic-plugins-pkg@1.2.3
[...]
InstallException: Error while installing plugin @my-company/my-fake-dynamic-plugins-pkg@1.2.3 with 'npm pack' : npm error code E404
npm error 404 Not Found - GET https://registry.npmjs.org/@my-company%2fmy-fake-dynamic-plugins-pkg - Not found
[...]

Expected results:

We should see the same error in 1.7.0 and 1.6.4, i.e., in 1.7.0, it should try to load the plugin from https://my-company.example.com

Reproducibility (Always/Intermittent/Only Once):

Always

Workaround in 1.7.0

As highlighted in this comment, the suggested workaround in 1.7.0 is to patch the deployment in the CR (by adding a new volume, volume mount and NPM_CONFIG_USERCONFIG env var in the init container), like so:

apiVersion: rhdh.redhat.com/v1alpha3
kind: Backstage
metadata: 
  name: my-rhdh
spec: 
  application: 
    dynamicPluginsConfigMapName: my-dynamic-plugins-rhdh
  # --- BEGIN WORKAROUND: Ensure you have the volumes, volume mounts and NPM_CONFIG_USERCONFIG env var listed below
  deployment: 
    patch: 
      spec: 
        template: 
          spec: 
            initContainers: 
              - name: install-dynamic-plugins
                volumeMounts: 
                  - mountPath: /opt/app-root/src/.my-dynamic-plugins-npmrc.dynamic-plugins
                    name: my-dynamic-plugins-npmrc
                env: 
                  - name: 
                  - name: NPM_CONFIG_USERCONFIG
                    # path before .npmrc should be the same as in the mountPath above
                    # file name .npmrc should be the same as key in the dynamic-plugins-npmrc secret above
                    value: /opt/app-root/src/.my-dynamic-plugins-npmrc.dynamic-plugins/.npmrc
            volumes: 
              - name: my-dynamic-plugins-npmrc
                secret: 
                  secretName: dynamic-plugins-npmrc
  # --- END WORKAROUND

documents

RHDHBUGS-2006 In 1.7, the Operator no longer mounts manual "dynamic-plugins-npmrc" Secrets for customized NPM registry

Closed

Assignee:: Priyanka Kantem

Reporter:: Armel Soro

Contributors:: Gennady Azarenkov

Team:: RHIDP - Documentation

Votes:: 0 Vote for this issue

Watchers:: 1 Start watching this issue

Created:: 2025/09/01 3:16 PM

Updated:: 2025/09/15 8:42 AM

Resolved:: 2025/09/03 2:16 PM

Details

Description

Description of problem:

Prerequisites (if any, like setup, operators/versions):

Steps to Reproduce

Actual results:

Expected results:

Reproducibility (Always/Intermittent/Only Once):

Workaround in 1.7.0

Attachments

Issue Links

Easy Agile Planning Poker

Activity

People

Dates

PagerDuty

Hide