chore(install-dynamic-plugins): consume installer from npm via root yarn workspace

[gustavolira]

Ready for review

Switches the dynamic-plugins installer from the vendored scripts/install-dynamic-plugins/ (carry-over from the Python era) to the npm package @red-hat-developer-hub/cli-module-install-dynamic-plugins, and deletes the vendored copy in the same PR now that the package is published.

The matching rhdh-plugins PR (#3246) is merged and @red-hat-developer-hub/cli-module-install-dynamic-plugins@0.2.0 is on the public npm registry. The root yarn.lock resolves against the published version.

What this PR does

1. build/containerfiles/Containerfile — drops the COPY of scripts/install-dynamic-plugins/{install-dynamic-plugins.cjs,install-dynamic-plugins.sh} and writes a small shim at /opt/app-root/src/install-dynamic-plugins.sh that delegates to the yarn-installed bin via install \"\$@\". Helm chart and Operator init-container spec keep invoking ./install-dynamic-plugins.sh /dynamic-plugins-root unchanged.
2. packages/backend/package.json + yarn.lock — declares @red-hat-developer-hub/cli-module-install-dynamic-plugins@0.2.0 as a runtime dependency of the backend workspace, not of the dynamic-plugins/ workspace. The Containerfile's build stage wipes dynamic-plugins/node_modules/ before the final stage runs (the === DELETE DYNAMIC PLUGINS/* === step keeps only dist/), so the dep has to live somewhere the === YARN WORKSPACES FOCUS === production install will hoist into /opt/app-root/src/node_modules/. Backend is private: true and is included in the production focus install, so the bin hoists correctly. (The dep originally sat on the root package.json, but yarn run monorepo:check (sherif) rejects dependencies on a private root; backend is the natural alternative — it's the runtime the init-container runs alongside.)
3. Bin path — the published package uses the string form of bin (\"bin/install-dynamic-plugins\"), so yarn names the symlink after the package's unscoped base name. The shim points at /opt/app-root/src/node_modules/.bin/cli-module-install-dynamic-plugins, not …/install-dynamic-plugins.
4. Deletes the vendored scripts/install-dynamic-plugins/ (46 files, ~7000 lines).
5. Cleans up references — .gitattributes, .dockerignore, codecov.yml, the two GitHub Actions workflows that tested the vendored copy (pr.yaml, coverage-baseline.yml), docs/dynamic-plugins/installing-plugins.md, docs/coverage/e2e-rhdh.md, and the rulesync-managed AI rule files. Also drops the orphan pytest test infrastructure (python/requirements-dev.{in,txt} and the Install Python dependencies step in pr.yaml) — TechDocs still uses python/requirements{,-build}.txt for the mkdocs venv, those stay.

Why yarn (and not npm install)

scripts/local-hermeto-build.sh already prefetches yarn deps for the repo root via cachi2/hermeto (the {\"type\": \"yarn\", \"path\": \".\"} entry in the fetch-deps call). Putting the installer as a yarn dep there reuses that existing prefetch — no infra change required in this repo or in the midstream Konflux pipeline.

An earlier revision of this PR used RUN npm install ... directly, which hit a real hermetic-build blocker: hermeto doesn't prefetch npm today, and Konflux runs with networking disabled. Wiring npm into hermeto would have spanned two repos (this one + the midstream). The yarn approach sidesteps that entirely.

Why we want to do this

Consuming the package from npm means:

• One source of truth — overlay repos and other RHDH consumers can npm install the same package instead of vendoring their own copies.
• ~7000 lines removed from this repo.
• The rhdh-plugins package follows the standard @backstage/cli-module-* convention: plain backstage-cli package build, no custom esbuild config, no keytar workaround.

Trade-offs (cold-start benchmark)

hyperfine, 50 runs warm cache, empty dynamic-plugins.yaml:

Variant	Bundle / install size	Median	σ
Bundled .cjs (pre-PR main)	231 KB single file	59 ms	±3 ms
npm install (cli-module dispatch, this PR's path)	25 MB node_modules	176 ms	±21 ms

~117 ms gap per pod start. On a 20-plugin install where skopeo pulls dominate (~60 s of total work) that's 0.2% — invisible in practice. Image build picks up ~25 MB from the new layer (one-time, cached in OCI registry).

Containerfile change details

• The installer lands at /opt/app-root/src/node_modules/.bin/cli-module-install-dynamic-plugins via the existing yarn install + === YARN WORKSPACES FOCUS === production step.
• Build-time install --help smoke check so a missing bin or a renamed install subcommand fails the image build instead of the init-container at pod start. cleye prints the subcommand usage and exits 0 before validating the required <dynamic-plugins-root> positional, so this check covers both "the bin resolved" and "the verb the shim invokes still exists".
• Shim at the original /opt/app-root/src/install-dynamic-plugins.sh path forwards \"\$@\" (not just \"\$1\") so any future positional argument the Helm chart or Operator passes is preserved.

Cleanup details

• .gitattributes — drops the linguist-generated marker for the vendored bundle and the surrounding orphan section header.
• .dockerignore — drops the dist/ exceptions that kept the bundle in the build context, and the orphan comment that explained them.
• codecov.yml — drops the install-dynamic-plugins flag (defined paths pointed at the long-removed Python files) and the comment that referenced it.
• .github/workflows/pr.yaml — drops the vitest test step + the install-dynamic-plugins codecov upload + the bundle-up-to-date verification step + the Install Python dependencies step that only existed to feed the pytest tests of the Python era.
• .github/workflows/coverage-baseline.yml — drops the pytest baseline that was still referencing the Python tests removed in feat(install-dynamic-plugins): port from Python to TypeScript/Node.js #4574.
• python/requirements-dev.{in,txt} — deleted; only contained pytest, pytest-cov, pytest-mock for the removed Python install script.
• docs/dynamic-plugins/installing-plugins.md — installer link points at the rhdh-plugins source.
• docs/coverage/e2e-rhdh.md — drops the vitest row from the coverage source table.
• .rulesync/rules/ci-e2e-testing.md + derived files under .claude/, .cursor/, .opencode/ — installer link points at the rhdh-plugins source.

🤖 Generated with Claude Code

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 55.25%. Comparing base (fe578e0) to head (dc18ca3).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4908      +/-   ##
==========================================
- Coverage   55.82%   55.25%   -0.58%     
==========================================
  Files         121      109      -12     
  Lines        2350     2132     -218     
  Branches      562      537      -25     
==========================================
- Hits         1312     1178     -134     
+ Misses       1033      953      -80     
+ Partials        5        1       -4     

Flag	Coverage Δ
rhdh	55.25% <ø> (-0.58%)	⬇️

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fe578e0...dc18ca3. Read the comment docs.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

The container image build workflow finished with status: cancelled.

[github-actions]

The container image build workflow finished with status: cancelled.

[github-actions]

The container image build workflow finished with status: failure.

[github-actions]

The container image build workflow finished with status: failure.

[github-actions]

The container image build workflow finished with status: failure.

[github-actions]

The container image build workflow finished with status: failure.

[github-actions]

The container image build workflow finished with status: cancelled.

[github-actions]

The container image build workflow finished with status: failure.

[github-actions]

The container image build workflow finished with status: cancelled.

[github-actions]

The container image build workflow finished with status: cancelled.

[github-actions]

The container image build workflow finished with status: cancelled.

[github-actions]

The container image build workflow finished with status: cancelled.

[github-actions]

The container image build workflow finished with status: cancelled.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

Image was built and published successfully. It is available at:

• quay.io/rhdh-community/rhdh:pr-4908
• quay.io/rhdh-community/rhdh:pr-4908-dc18ca3d

[nickboldt]

TL;DR the FOUR PAGE ai slopped description (please try to make these shorter in the future!)

But from my perspective as long as the yarn assets are in the yarn lock, this should work as intended when downstreaming for a hermetic build:

[kadel]

why constructing shell script directly in Containerfile? This looks weird, why not keeping install-dynamic-plugins.sh as regular file in repo? Is there benefit of doing this in Containerfile?

[gustavolira]

The shim is only 2 lines and uses the same path validated by the install --help smoke test. Keeping it inline makes validation and shim creation atomic, so any upstream change fails the build immediately instead of breaking at pod startup. Happy to move it to a checked-in .sh if preferred.

[kadel]

Why in backend and not in root package.json? PR description actually says that this is in root pakages.json

This is a build-time tool invoked in the Containerfile and the init-container — no backend
code imports it. Having it sit alongside actual backend runtime deps like
@backstage/backend-defaults feels a bit out of place.

If the only reason for moving it here was failing monorepo:check than this can be easily solved.
sherif supports per-dependency exceptions — adding this to root package.json would
keep the rule active for everything else:

  "sherif": {
    "ignoreDependency": ["@red-hat-developer-hub/cli-module-install-dynamic-plugins"]
  }

Could also be a nice opportunity to add a convenience script in root package.json:

  "scripts": {
    "install-dynamic-plugins": "cli-module-install-dynamic-plugins install"
  }

[gustavolira]

PR description updated. Sherif (monorepo:check) rejects dependencies on a private root, so moved it to packages/backend/package.json still gets hoisted by the production focus install, same bin path

[kadel]

@gustavolira Sorry, I missed your comment. I've updated my comment before I noticed your reply 😇 tldr: that check can be configured to ignore some packages