[red-hat-konflux]

This PR contains the following updates:

Package	Change	Age	Confidence
@patternfly/react-icons	6.6.0 → 6.6.1

---

Warning

Some dependencies could not be looked up. Check the warning logs for more information.

---

Release Notes

patternfly/patternfly-react (@​patternfly/react-icons)

v6.6.1

Compare Source

---

Configuration

📅 Schedule: (in timezone America/New_York)

• Branch creation
  • Between 12:00 AM and 07:59 AM, only on Monday (* 0-7 * * 1)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

To execute skipped test pipelines write comment /ok-to-test.

---

Documentation

Find out how to configure dependency updates in MintMaker documentation or see all available configuration options in Renovate documentation.

[red-hat-konflux]

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

• any of the package files in this branch needs updating, or
• the branch becomes conflicted, or
• you click the rebase/retry checkbox if found above, or
• you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: pnpm-lock.yaml

[ERR_PNPM_UNSUPPORTED_ENGINE] Unsupported environment (bad pnpm and/or Node.js version)

Your Node version is incompatible with "/tmp/renovate/repos/github/openshift-online/hypershell".

Expected version: >=24.18.1
Got: v24.11.0

This is happening because the package's manifest has an engines.node field specified.
To fix this issue, install the required Node version.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: 56d6992f-ec0d-4250-b72e-81820fedc99e

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[jsell-rh]

Amber review

Status: Complete

Verdict

COMMENT — no blockers. This is a low-risk, single-line Renovate/MintMaker bump of @patternfly/react-icons from 6.6.0 to 6.6.1 in the reusable gateway-management-ui package. The only issue is an intra-file version drift: the peerDependencies entry was bumped but the matching devDependencies entry (and the lockfile resolution) stayed at 6.6.0, so the package is not actually built/tested against the version it now declares it needs.

Amber Analysis

A dependency-only change with no Go/security/reconciler surface, so the HyperShell backend conventions (panic-free, error wrapping, SecurityContext, reconcile pattern, secret handling) are N/A here. The change is safe to ship; my one substantive note is a consistency gap that Renovate would normally have handled by moving both the peer and dev entries together.

Findings

[Minor] peerDependencies and devDependencies for @patternfly/react-icons now disagree — Dependency consistency (packages/gateway-management-ui/package.json L25 vs L37)

• peerDependencies["@patternfly/react-icons"] is bumped to 6.6.1 (L25), but devDependencies["@patternfly/react-icons"] remains 6.6.0 (L37), and pnpm-lock.yaml still resolves react-icons to 6.6.0 (importer specifier 6.6.0, resolution @patternfly/react-icons@6.6.0).
• Effect: this package declares that consumers must supply 6.6.1, yet it is compiled/type-checked/tested against 6.6.0. That is the exact version it is asking downstream (web-console) to install, so it is validated against a different version than it advertises.
• No CI break is expected from this alone: pnpm's lockfile tracks only dependencies/devDependencies specifiers, not peerDependencies, so --frozen-lockfile should still pass. But the drift is real and defeats the point of the bump.
• Fix: bump devDependencies["@patternfly/react-icons"] to 6.6.1 as well and regenerate pnpm-lock.yaml in the same PR, so dev/peer/lock all agree. Confidence: High.

Cross-PR coordination

I reviewed all other open PRs in openshift-online/hypershell (see list below). No material logical/structural/plan conflict with #189 was found — no duplicate solution, incompatible design, competing interface, or required change-ordering. There is one worth-noting coordination point:

• Update dependency @patternfly/react-core to v6.6.1 - autoclosed #188 chore(deps): update dependency @patternfly/react-core to v6.6.1 touches the same peerDependencies block in the same file (packages/gateway-management-ui/package.json) and uses the identical partial-update pattern: it bumps only the peer entry to 6.6.1 and leaves the devDependencies entry at 6.6.0. This is complementary, not competing — the two PRs move different PatternFly sub-packages. The coordination question for maintainers is ecosystem lockstep: PatternFly react-core/react-icons/react-table are expected to share a version, so after both merge you would have react-core@6.6.1 + react-icons@6.6.1 but react-table still 6.6.0, plus dev/peer drift in both. Suggest batching the PatternFly 6.6.1 bumps (and bumping react-table + the dev entries + lockfile together) rather than landing them piecemeal. This is a coordination preference, not a blocking design decision.
• chore(deps): update dependency react-intl to v10.1.20 #135 chore(deps): update dependency react-intl to v10.1.20 also edits the same file but a different (react-intl) line. Only a trivial textual rebase overlap — not a material conflict.
• Other PRs that touch packages/gateway-management-ui/ ([HYPERSHELL-129] feat(web-console): Adding section to gateway UI with instructions for sandbox connecting #208, [HYPERSHELL-259] feat: reconcile gateway version for CLI installation #210, fix(kind): expose gateway metrics and fix control plane connectivity #211, HYPERSHELL-112 Dashboard UI #209, Hypershell-154 UI with adjustments #214) modify source files under src/, not package.json, so they do not interact with this dependency pin.

Bottom line: no material cross-PR conflict; the only actionable coordination is aligning the PatternFly 6.6.1 bumps (#188/#189) so dev/peer/lock and sibling packages stay in lockstep.

Other open PRs reviewed for conflicts

#73, #75, #109, #135, #148, #150, #151, #179, #182, #185, #188, #194, #200, #201, #206, #207, #208, #209, #210, #211, #212, #214, #216.

Findings Summary (ordered by severity, highest first)

1. [Minor] peerDependencies react-icons bumped to 6.6.1 while devDependencies + lockfile stay at 6.6.0 — Dependency consistency (L25, L37)

Convention Checklist

Convention	Result
Image references consistent across the stack	Pass
Dependency pin consistent within file (peer vs dev vs lock)	Fail
Conventional commit message	Pass

[jsell-rh]

Verdict

COMMENT — no blockers. This is a low-risk, single-line Renovate/MintMaker bump of @patternfly/react-icons from 6.6.0 to 6.6.1 in the reusable gateway-management-ui package. The only issue is an intra-file version drift: the peerDependencies entry was bumped but the matching devDependencies entry (and the lockfile resolution) stayed at 6.6.0, so the package is not actually built/tested against the version it now declares it needs.

Amber Analysis

A dependency-only change with no Go/security/reconciler surface, so the HyperShell backend conventions (panic-free, error wrapping, SecurityContext, reconcile pattern, secret handling) are N/A here. The change is safe to ship; my one substantive note is a consistency gap that Renovate would normally have handled by moving both the peer and dev entries together.

Findings

[Minor] peerDependencies and devDependencies for @patternfly/react-icons now disagree — Dependency consistency (packages/gateway-management-ui/package.json L25 vs L37)

• peerDependencies["@patternfly/react-icons"] is bumped to 6.6.1 (L25), but devDependencies["@patternfly/react-icons"] remains 6.6.0 (L37), and pnpm-lock.yaml still resolves react-icons to 6.6.0 (importer specifier 6.6.0, resolution @patternfly/react-icons@6.6.0).
• Effect: this package declares that consumers must supply 6.6.1, yet it is compiled/type-checked/tested against 6.6.0. That is the exact version it is asking downstream (web-console) to install, so it is validated against a different version than it advertises.
• No CI break is expected from this alone: pnpm's lockfile tracks only dependencies/devDependencies specifiers, not peerDependencies, so --frozen-lockfile should still pass. But the drift is real and defeats the point of the bump.
• Fix: bump devDependencies["@patternfly/react-icons"] to 6.6.1 as well and regenerate pnpm-lock.yaml in the same PR, so dev/peer/lock all agree. Confidence: High.

Cross-PR coordination

I reviewed all other open PRs in openshift-online/hypershell (see list below). No material logical/structural/plan conflict with #189 was found — no duplicate solution, incompatible design, competing interface, or required change-ordering. There is one worth-noting coordination point:

• #188 chore(deps): update dependency @patternfly/react-core to v6.6.1 touches the same peerDependencies block in the same file (packages/gateway-management-ui/package.json) and uses the identical partial-update pattern: it bumps only the peer entry to 6.6.1 and leaves the devDependencies entry at 6.6.0. This is complementary, not competing — the two PRs move different PatternFly sub-packages. The coordination question for maintainers is ecosystem lockstep: PatternFly react-core/react-icons/react-table are expected to share a version, so after both merge you would have react-core@6.6.1 + react-icons@6.6.1 but react-table still 6.6.0, plus dev/peer drift in both. Suggest batching the PatternFly 6.6.1 bumps (and bumping react-table + the dev entries + lockfile together) rather than landing them piecemeal. This is a coordination preference, not a blocking design decision.
• #135 chore(deps): update dependency react-intl to v10.1.20 also edits the same file but a different (react-intl) line. Only a trivial textual rebase overlap — not a material conflict.
• Other PRs that touch packages/gateway-management-ui/ (#208, #210, #211, #209, #214) modify source files under src/, not package.json, so they do not interact with this dependency pin.

Bottom line: no material cross-PR conflict; the only actionable coordination is aligning the PatternFly 6.6.1 bumps (#188/#189) so dev/peer/lock and sibling packages stay in lockstep.

Other open PRs reviewed for conflicts

#73, #75, #109, #135, #148, #150, #151, #179, #182, #185, #188, #194, #200, #201, #206, #207, #208, #209, #210, #211, #212, #214, #216.

Findings Summary (ordered by severity, highest first)

1. [Minor] peerDependencies react-icons bumped to 6.6.1 while devDependencies + lockfile stay at 6.6.0 — Dependency consistency (L25, L37)

Convention Checklist

Convention	Result
Image references consistent across the stack	Pass
Dependency pin consistent within file (peer vs dev vs lock)	Fail
Conventional commit message	Pass

[jsell-rh]

This bumps the peer dependency to 6.6.1, but the devDependencies entry for @patternfly/react-icons (line 37, unchanged) is still 6.6.0, and pnpm-lock.yaml resolves it to 6.6.0. The package therefore declares consumers must supply 6.6.1 while it is itself built and tested against 6.6.0. Bump the dev entry to 6.6.1 and regenerate the lockfile in this PR so peer/dev/lock all agree. (No --frozen-lockfile break expected, since pnpm does not track peerDependencies specifiers in the lockfile.)

[jsell-rh]

Amber review

Status: Complete

Verdict

COMMENT - This is a low-risk Renovate patch bump of @patternfly/react-icons (6.6.0 -> 6.6.1) in the reusable gateway UI package. The change is safe to take, but it leaves the package internally inconsistent (peer requires 6.6.1, dev/tested against 6.6.0) and is one of a set of PatternFly bumps that should land together.

Findings

[Minor] peerDependencies and devDependencies diverge for @patternfly/react-icons - Consistency

packages/gateway-management-ui/package.json now declares @patternfly/react-icons": "6.6.1" under peerDependencies (L25) while devDependencies still pins 6.6.0 (L37). Because these are exact pins, the package now advertises a peer requirement for a version it never actually builds or tests against locally (the lockfile still resolves 6.6.0). It also introduces a version skew inside the PatternFly suite, since the sibling @patternfly/react-core and @patternfly/react-table peers remain at 6.6.0. 6.6.1 is a patch release so functional risk is low, but for consistency the devDependencies entry should be bumped to 6.6.1 in the same change (Renovate normally groups these). Confidence: High.

Note: since pnpm does not record peerDependencies specifiers in the lockfile importers section, no pnpm-lock.yaml update is required for this peer-only change; a devDependencies bump would require regenerating the lockfile.

Cross-PR coordination

The PatternFly React packages (@patternfly/react-core, @patternfly/react-icons, @patternfly/react-table) are conventionally kept on a single, lockstep version. Two other open PRs each bump one sibling of this same suite to 6.6.1 in the identical peerDependencies block of packages/gateway-management-ui/package.json: #188 (@patternfly/react-core) and #225 (@patternfly/react-table). Maintainers should decide to land #188, #189, and #225 as a coordinated set so the PatternFly peer versions stay aligned; merging any one alone leaves the suite in a mixed-version state (e.g. icons at 6.6.1 while core/table remain 6.6.0). Because all three edit adjacent lines of the same block, whichever merges first will force the others to rebase - sequence them intentionally rather than merging independently.

Findings Summary (ordered by severity, highest first)

1. [Minor] peerDependencies bumped to 6.6.1 while devDependencies (and lockfile) stay at 6.6.0, and the entry now diverges from the sibling PatternFly peers - Consistency (L25, L37)

Convention Checklist

Convention	Result
Image/dependency references consistent across the stack	Fail
Conventional commit message	Pass

[jsell-rh]

Verdict

COMMENT - This is a low-risk Renovate patch bump of @patternfly/react-icons (6.6.0 -> 6.6.1) in the reusable gateway UI package. The change is safe to take, but it leaves the package internally inconsistent (peer requires 6.6.1, dev/tested against 6.6.0) and is one of a set of PatternFly bumps that should land together.

Findings

[Minor] peerDependencies and devDependencies diverge for @patternfly/react-icons - Consistency

packages/gateway-management-ui/package.json now declares @patternfly/react-icons": "6.6.1" under peerDependencies (L25) while devDependencies still pins 6.6.0 (L37). Because these are exact pins, the package now advertises a peer requirement for a version it never actually builds or tests against locally (the lockfile still resolves 6.6.0). It also introduces a version skew inside the PatternFly suite, since the sibling @patternfly/react-core and @patternfly/react-table peers remain at 6.6.0. 6.6.1 is a patch release so functional risk is low, but for consistency the devDependencies entry should be bumped to 6.6.1 in the same change (Renovate normally groups these). Confidence: High.

Note: since pnpm does not record peerDependencies specifiers in the lockfile importers section, no pnpm-lock.yaml update is required for this peer-only change; a devDependencies bump would require regenerating the lockfile.

Cross-PR coordination

The PatternFly React packages (@patternfly/react-core, @patternfly/react-icons, @patternfly/react-table) are conventionally kept on a single, lockstep version. Two other open PRs each bump one sibling of this same suite to 6.6.1 in the identical peerDependencies block of packages/gateway-management-ui/package.json: #188 (@patternfly/react-core) and #225 (@patternfly/react-table). Maintainers should decide to land #188, #189, and #225 as a coordinated set so the PatternFly peer versions stay aligned; merging any one alone leaves the suite in a mixed-version state (e.g. icons at 6.6.1 while core/table remain 6.6.0). Because all three edit adjacent lines of the same block, whichever merges first will force the others to rebase - sequence them intentionally rather than merging independently.

Findings Summary (ordered by severity, highest first)

1. [Minor] peerDependencies bumped to 6.6.1 while devDependencies (and lockfile) stay at 6.6.0, and the entry now diverges from the sibling PatternFly peers - Consistency (L25, L37)

Convention Checklist

Convention	Result
Image/dependency references consistent across the stack	Fail
Conventional commit message	Pass

[jsell-rh]

[Minor] Peer/dev version drift. This bumps the peerDependencies pin to 6.6.1, but devDependencies (L37) and the lockfile still resolve @patternfly/react-icons@6.6.0. With exact pins, the package now declares a peer requirement for a version it never builds/tests against, and it diverges from the sibling PatternFly peers (react-core, react-table still 6.6.0). Please bump the devDependencies entry to 6.6.1 too (and regenerate pnpm-lock.yaml) to keep them consistent. Patch bump, so low functional risk.

[jsell-rh]

Amber review

Status: Complete

View the submitted review.

[jsell-rh]

Verdict

APPROVE-with-a-caveat is not available, so this is a COMMENT: the bump itself is valid, but this PR updates the @patternfly/react-icons version in only one of the three places it is declared, leaving the package's declared peer requirement, its dev/test dependency, and the lockfile disagreeing with each other. That inconsistency should be reconciled before merge, but it is not a security or data-integrity blocker.

Amber Analysis

This is a Renovate patch bump of @patternfly/react-icons 6.6.0 -> 6.6.1 in packages/gateway-management-ui/package.json. The change is limited to the peerDependencies block; devDependencies and pnpm-lock.yaml were not updated, so the package would now advertise a peer requirement it is neither built nor tested against.

Findings

[Major] react-icons version now disagrees across the same package - Dependency Consistency (packages/gateway-management-ui/package.json L25 vs L37)

• peerDependencies."@patternfly/react-icons" is now 6.6.1 (L25), but devDependencies."@patternfly/react-icons" is still 6.6.0 (L37).
• Consequence: the package declares it needs 6.6.1 from consumers, yet it is compiled, linted, and unit-tested (pnpm --filter @openshift-online/hypershell-gateway-management-ui check) against 6.6.0. A library should be developed and tested against the version it advertises as a peer.
• Fix: bump the devDependencies entry to 6.6.1 in the same PR so the declared peer and the build/test version match.
• Confidence: High.

[Major] Lockfile not regenerated - Dependency Consistency (pnpm-lock.yaml, not in diff)

• pnpm-lock.yaml still resolves @patternfly/react-icons at 6.6.0 (root importer L51 and devDependencies L288). The manifest change is not reflected in the lock, so an install/--frozen-lockfile CI step can fail or silently drift.
• Fix: run pnpm install (or pnpm --filter ... update) to regenerate the lockfile and include it in this PR.
• Confidence: High.

[Minor] PatternFly suite version skew - Dependency Hygiene (packages/gateway-management-ui/package.json L24-L26)

• After this change the peer set is react-core 6.6.0, react-icons 6.6.1, react-table 6.6.0. PatternFly ships react-core / react-icons / react-table as a coordinated suite and generally expects them aligned on the same version. Advancing one package alone is usually harmless for a patch release but is worth keeping aligned to avoid subtle type/style mismatches.
• Confidence: Medium.

Convention Checklist

Convention	Result
Conventional commit message	Pass
Config separate from code	Pass
Dependency manifest and lockfile consistent	Fail
Declared peer version matches tested version	Fail

Findings Summary (ordered by severity, highest first)

1. [Major] react-icons peer (6.6.1) and dev (6.6.0) versions disagree within the same package - Dependency Consistency (L25, L37)
2. [Major] pnpm-lock.yaml not regenerated to match the manifest change - Dependency Consistency
3. [Minor] PatternFly suite version skew (core/table 6.6.0, icons 6.6.1) - Dependency Hygiene (L24-L26)

Cross-PR coordination

No material cross-PR coordination issue requires maintainer action.

[jsell-rh]

This bumps @patternfly/react-icons to 6.6.1 only in peerDependencies. The devDependencies entry (line 37) is still 6.6.0, and pnpm-lock.yaml still resolves 6.6.0. As a result the package advertises a peer requirement it is neither built nor tested against.

Please also bump the devDependencies entry to 6.6.1 and regenerate pnpm-lock.yaml (pnpm install) in this PR so the declared peer, the dev/test version, and the lockfile agree. Also note the suite skew: react-core/react-table remain 6.6.0 while react-icons moves to 6.6.1.

[amber-review-bot]

Amber review

Status: Complete

View the submitted review.

[amber-review-bot]

Amber review

Status: Complete

View the submitted review.

[amber-review-bot]

Verdict

REQUEST_CHANGES. This bot bump moves @patternfly/react-icons to 6.6.1 only in the two workspace packages' peerDependencies while leaving their devDependencies, the consuming web-console app, and pnpm-lock.yaml pinned at 6.6.0, which produces an unmet-peer version skew and an out-of-sync lockfile. Because every CI job installs with pnpm install --frozen-lockfile, this should be regenerated as a complete, consistent bump before merge.

Findings

[Major] Lockfile not regenerated - --frozen-lockfile CI will fail. (Consistency / CI)
The PR changes peerDependencies in both package manifests but does not touch pnpm-lock.yaml, which still records @patternfly/react-icons at 6.6.0 for every importer. CI installs with pnpm install --frozen-lockfile in unit-tests.yml, checks.yml, e2e.yml, and the Makefile, so a manifest that no longer matches the committed lockfile will be rejected. The fix is to re-run the package manager so pnpm-lock.yaml is updated in the same commit. Confidence: High.

[Major] Version skew: peerDependencies at 6.6.1 but devDependencies / app pin 6.6.0. (Consistency)
packages/gateway-management-ui/package.json and packages/operational-dashboard-ui/package.json now declare an exact peer requirement of 6.6.1 (no caret), yet their own devDependencies (lines 37 and 42) and the consuming components/web-console/package.json dependency stay at 6.6.0. With an exact pin, 6.6.0 does not satisfy 6.6.1, so the packages are self-inconsistent (built and tested against 6.6.0 while advertising a 6.6.1 peer) and the app that consumes them provides an unsatisfied peer. All occurrences of @patternfly/react-icons should be bumped together. Confidence: High.

Cross-PR coordination

This change is one of a set of sibling PatternFly 6.6.1 bumps that all edit the same peerDependencies blocks in packages/gateway-management-ui/package.json and packages/operational-dashboard-ui/package.json and depend on the same shared pnpm-lock.yaml. The repository pins the PatternFly packages to a single exact version and previously kept them in lockstep at 6.6.0; landing them one at a time leaves mixed versions (for example react-icons at 6.6.1 beside react-core/react-table at 6.6.0), which can trigger intra-PatternFly peer mismatches, and each bump must regenerate the same lockfile. Maintainers should decide whether to batch these into one coordinated PatternFly 6.6.1 update (with a single lockfile regeneration) or define a merge order and rebase, rather than merging them independently:

• #188 (@patternfly/react-core to 6.6.1) - same peerDependencies blocks and shared lockfile.
• #225 (@patternfly/react-table to 6.6.1) - same peerDependencies block and shared lockfile.

Findings Summary (ordered by severity, highest first)

1. [Major] Lockfile not regenerated; pnpm install --frozen-lockfile CI jobs will reject the manifest/lockfile mismatch - CI / Consistency
2. [Major] peerDependencies bumped to 6.6.1 while devDependencies and consuming app stay at exact 6.6.0, an unmet-peer version skew - Consistency (gateway L25/L37, dashboard L23/L42)

Convention Checklist

Convention	Result
Image references / dependency versions consistent across the stack	Fail
Lockfile in sync with manifests (frozen-lockfile installs)	Fail

[amber-review-bot]

This bumps the peer requirement to an exact 6.6.1, but the devDependencies entry (line 37) and components/web-console/package.json still pin 6.6.0. An exact peer of 6.6.1 is not satisfied by 6.6.0, so this package is self-inconsistent (built/tested against 6.6.0) and its consumer provides an unmet peer. Also, pnpm-lock.yaml was not regenerated, so pnpm install --frozen-lockfile in CI will reject the mismatch. Bump all occurrences and update the lockfile in the same commit.

[amber-review-bot]

Same issue as the gateway-management-ui package: the peer requirement moves to exact 6.6.1 while devDependencies (line 42) stays 6.6.0 and pnpm-lock.yaml is untouched. Bump the dev dependency to match and regenerate the lockfile so frozen-lockfile installs stay green.