chore(deps): bump the github-actions group across 1 directory with 6 updates - #3212
Closed
dependabot[bot] wants to merge 1 commit into
Closed
chore(deps): bump the github-actions group across 1 directory with 6 updates#3212dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
dependabot
Bot
added
dependencies
dependabot
Bot
requested review from
a team,
durandom,
gashcrumb,
kadel and
subhashkhileri
as code owners
August 10, 2026 09:51
dependabot
Bot
added
dependencies
|
Hi @dependabot[bot]. Thanks for your PR. I'm waiting for a redhat-developer member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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. |
github-actions
Bot
added
the
non-workspace-changes
dependabot
Bot
force-pushed
the
dependabot/github_actions/github-actions-61c32fecf9
branch
from
August 11, 2026 18:03
94d77a1 to
bb58582
Compare
…updates Bumps the github-actions group with 6 updates in the / directory: | Package | From | To | | --- | --- | --- | | [actions/checkout](https://github.com/actions/checkout) | `6.0.2` | `7.0.1` | | [actions/setup-node](https://github.com/actions/setup-node) | `6.4.0` | `7.0.0` | | [fullsend-ai/fullsend/.github/workflows/reusable-dispatch.yml](https://github.com/fullsend-ai/fullsend) | `0.32.0` | `0.35.1` | | [actions/setup-python](https://github.com/actions/setup-python) | `6.2.0` | `7.0.0` | | [docker/login-action](https://github.com/docker/login-action) | `4.1.0` | `4.6.0` | | [actions/stale](https://github.com/actions/stale) | `10.2.0` | `11.0.0` | Updates `actions/checkout` from 6.0.2 to 7.0.1 - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@de0fac2...3d3c42e) Updates `actions/setup-node` from 6.4.0 to 7.0.0 - [Release notes](https://github.com/actions/setup-node/releases) - [Commits](actions/setup-node@48b55a0...8207627) Updates `fullsend-ai/fullsend/.github/workflows/reusable-dispatch.yml` from 0.32.0 to 0.35.1 - [Release notes](https://github.com/fullsend-ai/fullsend/releases) - [Commits](fullsend-ai/fullsend@3cfa255...19b3583) Updates `actions/setup-python` from 6.2.0 to 7.0.0 - [Release notes](https://github.com/actions/setup-python/releases) - [Commits](actions/setup-python@a309ff8...5fda3b9) Updates `docker/login-action` from 4.1.0 to 4.6.0 - [Release notes](https://github.com/docker/login-action/releases) - [Commits](docker/login-action@4907a6d...dbcb813) Updates `actions/stale` from 10.2.0 to 11.0.0 - [Release notes](https://github.com/actions/stale/releases) - [Changelog](https://github.com/actions/stale/blob/main/CHANGELOG.md) - [Commits](actions/stale@b5d41d4...4391f3d) --- updated-dependencies: - dependency-name: actions/checkout dependency-version: 7.0.1 dependency-type: direct:production update-type: version-update:semver-major dependency-group: github-actions - dependency-name: actions/setup-node dependency-version: 7.0.0 dependency-type: direct:production update-type: version-update:semver-major dependency-group: github-actions - dependency-name: actions/setup-python dependency-version: 7.0.0 dependency-type: direct:production update-type: version-update:semver-major dependency-group: github-actions - dependency-name: actions/stale dependency-version: 11.0.0 dependency-type: direct:production update-type: version-update:semver-major dependency-group: github-actions - dependency-name: docker/login-action dependency-version: 4.6.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: github-actions - dependency-name: fullsend-ai/fullsend/.github/workflows/reusable-dispatch.yml dependency-version: 0.35.1 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: github-actions ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
force-pushed
the
dependabot/github_actions/github-actions-61c32fecf9
branch
from
August 12, 2026 20:51
bb58582 to
d6a0a45
Compare
|
gustavolira
pushed a commit
that referenced
this pull request
Aug 17, 2026
…ailing The `smoke` check has been red since 2026-08-10 — including on PRs that change nothing but GitHub Actions SHAs (#3212) — with: Acquire connection error: Error: Could not locate the bindings file status: fail-start Cause: #3180 bumped the `packageManager` pin to yarn@4.17.1, and that release makes `enableScripts: false` the default (`yarn config enableScripts` now reports `Source: <default>, Value: false`). `better-sqlite3` therefore never builds its native binding, so `startTestBackend()` cannot open its in-memory database and every backend boot fails. The last green run is the last one whose log still says "better-sqlite3 must be built because it never has been before". Nothing about the failure names yarn or install scripts, which is why it read as a harness bug: the plugins load fine (`backend loaded 3/3`) and only the boot fails. Opt that one package into building via `dependenciesMeta` rather than setting `enableScripts: true` for the whole tree — `isolated-vm`, `keytar`, `cpu-features`, `ssh2`, `protobufjs` and `esbuild` all list install scripts too, and none of them need to run for this harness. Yarn's safer new default stays in place for them. Verified locally against a real workspace, reproducing and then fixing: before: backend loaded 3/3, start=false, status: fail-start after: backend loaded 3/3, start=true, status: pass `yarn install --immutable` is clean; the lockfile change is the 3-line `dependenciesMeta` entry. This is unrelated to the rest of this PR — it is fixed here because it gates the same check. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
gustavolira
pushed a commit
that referenced
this pull request
Aug 17, 2026
…ailing The `smoke` check has been red since 2026-08-10 — including on PRs that change nothing but GitHub Actions SHAs (#3212) — with: Acquire connection error: Error: Could not locate the bindings file status: fail-start Cause: #3180 bumped the `packageManager` pin to yarn@4.17.1, and that release makes `enableScripts: false` the default (`yarn config enableScripts` now reports `Source: <default>, Value: false`). `better-sqlite3` therefore never builds its native binding, so `startTestBackend()` cannot open its in-memory database and every backend boot fails. The last green run is the last one whose log still says "better-sqlite3 must be built because it never has been before". Nothing about the failure names yarn or install scripts, which is why it read as a harness bug: the plugins load fine (`backend loaded 3/3`) and only the boot fails. Opt that one package into building via `dependenciesMeta` rather than setting `enableScripts: true` for the whole tree — `isolated-vm`, `keytar`, `cpu-features`, `ssh2`, `protobufjs` and `esbuild` all list install scripts too, and none of them need to run for this harness. Yarn's safer new default stays in place for them. Verified locally against a real workspace, reproducing and then fixing: before: backend loaded 3/3, start=false, status: fail-start after: backend loaded 3/3, start=true, status: pass `yarn install --immutable` is clean; the lockfile change is the 3-line `dependenciesMeta` entry. This is unrelated to the rest of this PR — it is fixed here because it gates the same check. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
gustavolira
added a commit
that referenced
this pull request
Aug 18, 2026
…ess denominator (#3282) * feat(smoke-tests-native): validate module-federation remote shape, not just presence The frontend half of the harness checked that `dist/mf-manifest.json` exists. Presence is not enough: the remotes router in @backstage/backend-dynamic-feature-service logs the reason and `continue`s past a manifest missing any field it needs, so `GET /.backstage/dynamic-features/remotes` still answers `200 []`. What reaches the browser is an app that boots cleanly with no plugins and no error — the failure shape that is hardest to notice. Validate what that router actually requires (`name`, `metaData.remoteEntry.name`, a non-empty `exposes`, and the remote entry asset on disk) and report it per package as `frontend.bundles[].mf`. `servable` and `nfsFeatures` are reported apart because they are two different problems: - `servable: false` is an artifact defect and fails the run. - `nfsFeatures: []` on a servable remote is upstream migration state — the remote is served, but nothing it exposes carries a feature type the new frontend system mounts — so it warns. Nine published frontend packages are in that state today (argocd, qe-theme, the six @roadiehq/*, and plugin-techdocs-module-addons-contrib); failing them would turn six workspaces red for work that belongs upstream. Verified against real published artifacts: `--workspace acr` reports a servable remote with two NFS entry points, and `--workspace theme` warns on qe-theme while staying green. Two existing tests wrote `{}` as the manifest body and passed on presence alone; they now carry the shape observed on backstage-community-plugin-acr:bs_1.52.0__1.27.0. Refs: RHIDP-15286, RHIDP-15082, RHIDP-16009 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(nfs-readiness): count frontend-plugin-module as frontend surface The report's role filter admitted only `frontend-plugin`, so every `frontend-plugin-module` package was bucketed `backend-only` — "not applicable" — even though those packages carry `backstage.features` and load through the same module-federation remote as a plugin. Five packages were invisible and four of them are already NFS-ready: @red-hat-developer-hub/backstage-plugin-analytics-module-adoption-insights nfs-ready @backstage-community/plugin-analytics-module-ga4 nfs-ready @backstage-community/plugin-analytics-module-matomo nfs-ready @backstage-community/plugin-analytics-module-newrelic-browser nfs-ready @backstage/plugin-techdocs-module-addons-contrib no-features The published total therefore read 75 frontend packages where the real surface is 80. The bug appeared twice — once in the classification branch, and again in the jq filters computing the markdown denominators, so fixing only the first would have classified a module correctly and then left it out of the count printed next to it. Also document two ways the counts mislead, in the report's own output: - `mixed` and `legacy-only` are structurally unreachable. Both need `backstage.features` to be non-empty while containing no NFS type, but the CLI populates that field *from* the entry points it detects, so a plugin with no NFS entry point gets an empty field and lands in `no-features`. A `mixed: 0 / legacy-only: 0` line is the expected output shape, not a clean bill of health. - `no-features` merges two states this report cannot separate: a package shipping no MF bundle at all, and one whose served remote merely exposes no NFS entry point. @roadiehq/backstage-plugin-{argo-cd,datadog,github-insights} are the second kind — they do expose an `alpha` module. smoke-tests-native reports that distinction. Refs: RHIDP-15286 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs: add the NFS e2e triage sheet for RHIDP-15286 Reference material for the epic's per-workspace tickets: what the NFS migration actually requires per workspace, whether the suite still needs OpenShift once migrated, and what its assertions are really about. Three things it records that were not written down anywhere: - The unit of cluster cost is the Playwright project, not the workspace. The 24 workspaces declare 46 projects (the project name is the namespace, and `-app-next` is what switches e2e-test-utils into NFS mode) and 246 tests. Six app-next lanes exist, two skipped in nightly. "One task per workspace" is really ~40 lanes. - "Needs a cluster" and "needs a live external service" are different constraints, and only the first costs a cluster claim. Classifying by that — none / svc / ctr / ocp — puts about 29 of the 46 projects outside OpenShift, three of them needing no external dependency at all. That is a bound on what a cluster-free lane could cover, not a plan. - The migration recipe as the four merged workspaces actually did it, including the two locator diffs (acr's "ACR IMAGES" vs "Image Registry", tekton's "Tekton" vs "CI"). Those are not flakiness: under NFS the suites' Scalprum mountPoints config is inert and the tab comes from the plugin's own EntityContentBlueprint. They are the epic's own evidence that a large share of these assertions are about declarative wiring. It proposes no spec deletion, and the workspaces whose subject is OpenShift stay on Prow. Two per-workspace columns are there to be checked before a lane is written: `artifact` (several suites load RHDH's baked-in copy rather than the artifact this repo publishes, so an NFS lane inherits that) and `scalprum` (config keys NFS does not read, each needing an `app.extensions` equivalent or the plugin loads and contributes nothing). Refs: RHIDP-15286, RHIDP-15287, RHIDP-15082, RHIDP-16009 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(smoke-tests-native): build better-sqlite3 so backend boots stop failing The `smoke` check has been red since 2026-08-10 — including on PRs that change nothing but GitHub Actions SHAs (#3212) — with: Acquire connection error: Error: Could not locate the bindings file status: fail-start Cause: #3180 bumped the `packageManager` pin to yarn@4.17.1, and that release makes `enableScripts: false` the default (`yarn config enableScripts` now reports `Source: <default>, Value: false`). `better-sqlite3` therefore never builds its native binding, so `startTestBackend()` cannot open its in-memory database and every backend boot fails. The last green run is the last one whose log still says "better-sqlite3 must be built because it never has been before". Nothing about the failure names yarn or install scripts, which is why it read as a harness bug: the plugins load fine (`backend loaded 3/3`) and only the boot fails. Opt that one package into building via `dependenciesMeta` rather than setting `enableScripts: true` for the whole tree — `isolated-vm`, `keytar`, `cpu-features`, `ssh2`, `protobufjs` and `esbuild` all list install scripts too, and none of them need to run for this harness. Yarn's safer new default stays in place for them. Verified locally against a real workspace, reproducing and then fixing: before: backend loaded 3/3, start=false, status: fail-start after: backend loaded 3/3, start=true, status: pass `yarn install --immutable` is clean; the lockfile change is the 3-line `dependenciesMeta` entry. This is unrelated to the rest of this PR — it is fixed here because it gates the same check. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(smoke-tests-native): align MF validation with the router's actual guards Review of this PR found the shape check did not match the router it claims to mirror. Three divergences, verified against the installed @backstage/backend-dynamic-feature-service source and against real published artifacts: 1. `exposes: []` was reported as a failure. It is not one — the router's guard is `!exposes || !Array.isArray(exposes) || !exposes.every(...)`, and `[]` is truthy, is an array, and `[].every()` is vacuously true. The remote is served; it just exposes nothing. Failing it would have failed an artifact that works, and the previous commit locked that in with a green test. 2. An `exposes` entry missing a `name` was NOT reported. That is the case the router does reject, and the old `.filter()` silently dropped the bad entry and passed as long as some other entry survived — exactly the "defect invisible at runtime" this check exists to catch. Now mirrors the router's `.every()` predicate verbatim. 3. `metaData.remoteEntry.path` was ignored. Real manifests emit it alongside `name` (empty for a root-level entry, a subdirectory otherwise), so resolving `dist/<name>` alone reported a missing asset for a bundle the MF runtime loads fine. Also stop gating the whole module-federation branch on a file literally named `remoteEntry.js`. The router's default `getRemoteEntryType()` is `"manifest"`, so it serves mf-manifest.json as the entry and the asset can be named anything the manifest declares. Gating on the filename hid such remotes entirely: with no `dist-scalprum/` the bundle was reported as having no frontend layout at all, and with one it was counted as legacy-only — the same undercount the readiness-report role filter was making. And add `nfsFeaturesExposed`: `backstage.features` was read without checking the manifest actually exposes those entry points. A package declaring `./alpha` while exposing only `.` left NFS nothing to resolve, yet both `servable` and `nfsFeatures` looked healthy, so no warning fired. The gap widened once empty `exposes` became servable. `nfsFeaturesExposed` is the field to judge "will NFS mount anything" by; `nfsFeatures` still reports what the package declares. Each behaviour was made to fail first, then fixed: the three new tests go red on the old code, and mutating `nfsFeaturesExposed` back to `nfsFeatures`, dropping the `path` segment, or restoring the `remoteEntry.js` gate each turns its own test red. Docs corrected in the same commit: both the README field table and the triage sheet claimed the router requires a non-empty `exposes`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * refactor(smoke-tests-native): make the NFS-entry-point signal testable Mutation testing during review showed the warn branch had no test and could not get one: `native-smoke.ts` ends in `process.exit(await main())`, so nothing in it is importable, and `validateFrontends` is not exported. Deleting the branch left every test green. The package already has the answer to this — `harness-logic.ts` exists precisely so the harness's pure decisions can be tested away from the I/O shell (`computeStatus`, `describeInstallShortfall`, `partitionBootable`). So `isServableWithoutNfsEntryPoint` moves there with five cases covering the two inputs that matter, including the one the inline condition got wrong: a package declaring an NFS feature the remote does not expose. Mutating the predicate back to `nfsFeatures` turns that test red. Also make `mf` required on `FrontendBundleInfo` rather than `mf?: … | null`. Every producer sets it; the optionality existed only so five pre-PR object literals in `aggregate-report.test.ts` kept compiling. A type that says "optional" because a test omits it documents the test, not the system — the literals now carry `mf: null`. While here, the module docstring in `native-smoke.ts` still described step 4 as "presence only, never executed", which this PR falsified. It is the first thing a reader sees, so it is corrected to say what the two halves now do. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * refactor(nfs-readiness): decide "is frontend surface" once, and cover every reader All three reviewers flagged the same thing independently: the previous commit fixed the role filter but left the question answered two different ways — an exact-pair test in the classifier and `startswith("frontend-plugin")` in three jq filters eighty lines below. That is not hypothetical drift. Driven with a fixture whose role is `frontend-plugin-widget`, the package is counted in the frontend total, printed in the frontend tier table with status `backend-only`, and printed again in the backend-only table — the same package in both, under a tier header claiming a ratio for something never classified. Latent today (metadata carries exactly four roles: 75 `frontend-plugin`, 5 `frontend-plugin-module`, 55 `backend-plugin`, 51 `backend-plugin-module`), but two expressions of one predicate is how the classifier and the denominator came apart in the first place. So decide it once, in `is_frontend_role()`, and carry the answer in the emitted JSON as `frontend`. The three filters now `select(.frontend)` instead of re-deriving it. Test coverage followed the same review: mutation testing showed the two per-tier filters were entirely uncovered — narrowing either one passed all five tests, silently dropping a row from the table and a unit from the header count. And `test_backend_roles_stay_out_of_the_frontend_denominator` named the denominator while asserting only a package's status, so a mutant sweeping `backend-plugin-module` into the frontend total passed it; it is renamed to what it actually checked, and the markdown fixture gained both backend roles so the denominator assertion constrains something. All three mutants are now killed. The tests also now use `shell_harness.run_script` rather than hand-rolling `subprocess.run` twice with `__import__("os").environ["PATH"]` inline — that helper already exists for exactly this, is used by two sibling suites, and brings a scrubbed environment and a timeout the hand-rolled version lacked. `NFS_SCRIPT` joins the other script constants. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(smoke-tests-native): keep `servable` meaning what it says, and match nfsModuleFilter Second review pass, against the real `@backstage/backend-dynamic-feature-service` router and `rhdh:packages/backend/src/modules/nfsModuleFilter.ts`. Four corrections, three of them to code the first pass wrote. **`servable` was false for remotes the router serves.** The field is documented as the router's verdict, but a missing or escaping remote-entry asset was folded into the same `problems` list as the router's own guards, so it flipped `servable` and prefixed the message with "would be skipped by the remotes router". On the default path the router probes mf-manifest.json itself (`getRemoteEntryType()` returns `"manifest"`) and never reads `metaData.remoteEntry.path` at all — it serves those remotes. Router guards and bundle faults are now separate: only the former sets `servable`, and the message says which kind it is. Three tests asserted the old behaviour and were encoding the bug; they now pin the documented meaning. **The entry-point mapping is now prefix-insensitive, and the dead branch is gone.** `exposedNameOf` special-cased `"."`, but `".".replace(/^\.\//, "")` is already `"."` — the branch could not change an answer, which is why mutating it away changed nothing. `canonicalEntryPoint` normalises both sides instead, matching `nfsModuleFilter`'s own `moduleName === '.' || startsWith('./') ? moduleName : './' + moduleName`. Stripping only one side assumed the two agree on the prefix; a manifest emitting `"./alpha"` literally would have been reported as exposing nothing. **The `exposes` guard's crash paths are now covered.** Only the `"name" in e` conjunct was pinned; dropping `e !== null` or `typeof e === "object"` left every test green. Both are crash paths — `"name" in null` throws, nothing catches it, and the throw escapes `validateFrontendBundle` to abort the whole sweep rather than fail one package. One fixture array covers all three. **`"."` is on the hot path and was untested.** 12 of the 44 published frontend artifacts declare `"."` as their NFS entry point; no fixture exercised that half of the mapping. Also: the JSDoc and the README layout table still required `dist/remoteEntry.js` for the new frontend system, which the previous commit stopped doing — and a test assertion pinned that stale guidance, so correcting the message turned it red. Every behaviour was made to fail first, and each fix was verified to kill its own mutant. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(smoke-tests-native): stop claiming NFS mounts nothing when metadata cannot say The warning this PR added asserted "NFS will mount nothing" for any servable remote with no reachable NFS entry point. For the larger of the two cases that is not true, and the claim had already reached 19 Jira tickets before the check surfaced it. `rhdh:packages/backend/src/modules/nfsModuleFilter.ts`: if (!features || Object.keys(features).length === 0) { return undefined; } With no `backstage.features`, the filter installs **no** resolver — so the router advertises *every* exposed module and `@backstage/frontend-dynamic-feature-loader` decides at runtime by the `$$type` of each module's default export. `backstage.features` narrows what is advertised; it does not gate loading. So "declares nothing" means "cannot be told from metadata", not "mounts nothing". `isServableWithoutNfsEntryPoint` becomes `describeNfsShortfall`, returning the message for whichever case applies: - declares NFS entry points but does not expose them → the filter keeps no modules, so NFS mounts nothing. Definitive. - declares no `backstage.features` → the filter is bypassed; only executing the bundle can say. The harness now says that instead of guessing. Moving the text into `harness-logic.ts` also puts it under test — the previous commit made the decision testable but left the message itself in the unreachable `process.exit()`-terminated module. `docs/nfs-e2e-triage.md` carried the same wrong claim about the nine `no-features` packages and is corrected with the mechanism and the practical consequence: do not assume a lane for those workspaces shows an empty page, and do not assume it works either. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * refactor(nfs-readiness): pin the predicate's exactness, and stop duplicating it again Mutation testing found the previous commit's own thesis unguarded: changing `contains_exact`'s `==` to a prefix glob passed all seven tests. Exact-match-versus-prefix is precisely what that commit was about — its message walks through a `frontend-plugin-widget` fixture landing in both the frontend tier table and the backend-only table at once — but that fixture never landed. It does now, and it kills the mutant. The same commit also consolidated one duplicated predicate and created another: `is_frontend_role` and `is_nfs_type` were the same loop, same exact match, same return convention, one having been given `local` for its loop variable and the other not. Both now delegate to `contains_exact`. And the classifier converted the predicate's exit code into the string `"true"`/`"false"` and then re-tested the *string* — re-asking, four lines later, the question the change exists to answer once. Flattened. Smaller items from the same pass: a `_markdown()` helper so the two markdown tests stop repeating the invocation; `cwd=repo_root` passed through so the fixture's hermeticity claim holds by construction rather than by the script addressing everything through `REPO_ROOT`; and `shell_harness.py`'s docstring, which still called itself coverage-only and omitted `REPO_ROOT` — the seam this whole suite depends on. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * refactor: clear the five SonarCloud issues this PR introduced All five are mine, and the interesting one is a consequence of the review passes rather than of the original change. **typescript:S3776 — `inspectMfRemote` cognitive complexity 20 > 15** (`loader.ts`). The function accreted across two review passes: parse, extract four manifest fields, mirror the router's guards, resolve and contain an untrusted path, probe the asset, intersect the NFS entry points. It had grown two adjacent comments saying nearly the same thing about what the router does not check — a reliable sign one body was holding several ideas. Split into `readManifestFields`, `routerGuardProblems` and `bundleAssetProblems`, which also gives the router-versus-bundle distinction the previous commit introduced a name instead of a comment. **typescript:S7776 — `NFS_FEATURE_TYPES` should be a `Set`** (`loader.ts`). It was an array because an earlier review finding asked for the `as const` type assertion to go. A `Set` is better still, and it is what `rhdh:packages/backend/src/modules/nfsModuleFilter.ts` uses for the same list. **typescript:S6582 — prefer an optional chain** (`harness-logic.ts`). `mf === null || !mf.servable` becomes `!mf?.servable`; the two agree on all three inputs, and mutating the guard away still turns a test red. **shelldre:S7679 ×2 — assign the positional parameter to a local** (`nfs-readiness-report.sh`). Introduced by the `contains_exact` extraction the last commit made: the two one-line delegations passed `$1` straight through, so neither said what its parameter was. Gates: `yarn check` green (130 tests), `pytest` green (442), shellcheck clean, and the harness re-verified against the published `acr` and `theme` artifacts. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(smoke-tests-native): do not let an unreadable package.json read as "declares nothing" From the fullsend review (finding: edge-case, `loader.ts` `readNfsFeatures`). Its own severity assessment was "very low", and that was right when the code was written — it is not right any more, which is why this is worth fixing rather than noting. The catch is unreachable for malformed JSON: `discoverPlugins` skips such packages and warns before `validateFrontendBundle` ever runs, and `validateFrontendBundle` returns early when package.json is absent. So only a genuine I/O error reaches it. What changed is the meaning of the value it returns. Since `describeNfsShortfall` branches on `nfsFeatures.length === 0` to say "declares no backstage.features, so nfsModuleFilter installs no filter", an EISDIR or EACCES would now be reported as a fact about the artifact. Stating a read failure as a verdict is precisely the mistake this PR fixed twice already. It now warns loudly and says what it is doing, matching how `discoverPlugins` handles the same class of problem two functions up, and reusing `errorMessage` from `./util`. Tested by making package.json a directory — `existsSync` passes, `readFileSync` throws EISDIR — which reaches the catch deterministically and portably. Made to fail first; restoring the silent `return []` turns it red. The other four findings from that review are not applied; see the PR discussion for which and why. One of them (`!mf?.servable`) would reintroduce SonarCloud S6582, and the bot retracts it in the same sentence it raises it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(smoke-tests-native): name the real schemaVersion consumers Answers the fullsend review on report.ts:28 ("Verify no external consumer checks schemaVersion"). Verified: there is none. The consumers are `sweep.ts` via `isReport`, and `aggregate.ts` via `isSweepSummary` plus `aggregate-report.ts` reading `report.frontend.bundles[]` — all three inside this package and all updated in this PR. Two things that look like consumers and are not: - `native-smoke.yaml` and `community-plugin-sweep.yaml` move these files around as artifacts but never parse `schemaVersion`. The sweep's `download-artifact` has no `run-id`, so it only ever reads the current run's shards — an older schema cannot reach a newer aggregator. (The one workflow that does fetch across runs, `workspace-tests.yaml`, fetches `published-exports-pr-N` from `pr-actions.yaml`, a different artifact entirely.) - Every other `results.json` in the repo is Playwright's report — `run-e2e.sh`, `e2e-triage-agent.yaml`, the e2e-failure-analysis skill — and `check-backstage-compatibility.yaml`'s `"schemaVersion": 1` is a shields.io badge. Recording that in the comment because of what the verification turned up: the comment claimed "the parity runs comparing native vs Docker verdicts" parse this file, and no such consumer exists anywhere in the repo. That comment is the checklist a future maintainer reads before a bump, so a phantom entry in it is worse than no list. It now names the three real ones and says that is the whole set. No behaviour change; the exact-match guard is deliberate and documented, and stays. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * refactor(smoke-tests-native): use errorMessage() in the manifest-parse catch From the fullsend review (finding: error-message-format). The catch in `inspectMfRemote` still inlined `err instanceof Error ? err.message : String(err)` while `readNfsFeatures`, about 130 lines away in the same file, calls `errorMessage()` from `./util` — which is exactly that ternary. I introduced the inconsistency in the previous commit by importing the helper for one catch and leaving the other on the inline form. Not touched: the same inline ternary in `loadBackendPlugins`. It predates this PR and is outside the diff, so it stays for a separate change rather than widening this one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test+refactor(smoke-tests-native): pin the empty exposes name, and name the helpers verb-first Two non-blocking observations from the fullsend review, both verified before acting. **Empty `exposes` name was an unpinned boundary.** Checked against the router's guard: `"name" in {name: ""}` is true, so it does not skip the remote — it advertises `[""]` as an exposed module. So `servable` must stay true to mirror it, while the empty name is dropped from the usable list because NFS has nothing to resolve for it. Both halves are now pinned: mutating the length filter away, and mutating the guard to reject empty names, each turn the new test red. The behaviour was already right; only the test was missing. **`routerGuardProblems` / `bundleAssetProblems` → `findRouterGuardProblems` / `findBundleAssetProblems`.** The package leans verb-first for anything non-trivial (`accumulate*`, `build*`, `collect*`, `compute*`, `derive*`, `describe*`, `discover*`, `find*`, `load*`, `parse*`, `read*`, `resolve*`, `select*`, `validate*`), and `findSummaries` already establishes `find` here. `check*` was suggested but reads as returning a boolean; these return the problems, so `find*` says both what it does and what comes back. Not applied, for the third time asked: splitting the `better-sqlite3` fix into its own PR. It is 5 lines and it unblocks the `smoke` job that validates this PR's own changes, so the bisect-history argument does not outweigh reopening a PR already awaiting human approval. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix: reconcile with #3284, which replaced the report's baked-in status Rebase onto origin/main brought in #3284 ("infer NFS readiness for baked-in plugins from source exports"), which removes the `baked-in` status entirely: a plugin with a local dist path now has its `backstage.features` inferred from the upstream package.json exports, so it lands in `nfs-ready` or `unknown` instead. The textual conflict was one hunk; the semantic fallout was larger and is what this commit handles. **The pytest case asserted the dead status.** Its property is still the one that matters — a `frontend-plugin-module` with a local path must reach the classification branch rather than being short-circuited to `backend-only` — and that branch is precisely what #3284 rewrote. Renamed to say what it pins, and it now asserts `frontend is True` and `status == "unknown"`, which is the honest answer for a fixture with no `source.json`: inference cannot run. Exercising a successful inference needs network access to raw.githubusercontent.com, which this hermetic suite deliberately does not have. **`baked-in` now meant two different things in the triage sheet.** The `artifact` column is my own vocabulary for which copy an e2e suite loads (the published OCI artifact or RHDH's bundled one) — a different question from the report's classification, and unaffected. The two rows that used the report's sense are corrected: `extensions` is still not published as OCI, so the MF-manifest check cannot reach it, but the report now infers `nfs-ready` for it from source. The column legend says explicitly that it is not the report's status. Verified the two changes compose rather than just co-exist: the merged script reports **80 total frontend plugins** (the denominator fix from this PR, up from 75) *and* `extensions` as `nfs-ready` with `{"./alpha": "@backstage/FrontendPlugin"}` (the inference from #3284). Gates after rebase: 132 TS tests, 442 python tests, shellcheck clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(smoke-tests-native): stop a failed read from becoming an NFS verdict From the fullsend review of the rebased head (finding: [medium] logic-error). Correct, and it is the half I left undone one commit earlier: I made `readNfsFeatures` warn on an I/O error but left it returning `[]`, and `describeNfsShortfall` then said "the remote is served but declares no backstage.features" — a statement about the artifact derived from a failure to look at it. My own test named that gap and asserted only the warning. Relying on the caller's control flow to suppress the verdict is not enough, and that is what settled the approach. `validateFrontends` happens to skip the warning branch when there is an error, but `describeNfsShortfall` is exported and callable on any `mf`, and more to the point the misleading record is *persisted*: a consumer reading `mf.servable: true, mf.nfsFeatures: []` out of results.json cannot tell an I/O error from a package that declares nothing. So `MfRemoteInfo` gains `nfsFeaturesError`, `describeNfsShortfall` returns null when it is set, and the read failure also joins the bundle problems so the run fails and says why. Schema 4 → 5, with the changelog line and the consumer list already documented two commits back. Two smaller findings from the same review, both verified first: - The combined error read "would be skipped by the remotes router … is servable but its bundle is broken" when both problem sets fired — self-contradictory, and I wrote that wording. Now "has bundle problems"; whether it is servable is `mf.servable`, not the string's job. - The "declaring no features" test leaned on the `mfRemote()` factory defaults without asserting them, so a later change to those defaults would have left it matching a message about a different state. It now pins its own inputs. Also groups the shell-script tests into `TestClassification` / `TestMarkdownOutput`, matching the class-based style 13 of the 17 sibling suites in `scripts/tests/` use, and separating two groups that until now differed only by a comment and their fixture. Not applied: renaming `MfManifestFields.exposes` to `usableExposes`. It feeds `MfRemoteInfo.exposes`, which is in the results.json schema and must keep its name — giving the internal field a different name would imply the two hold different data when one is just the filtered form of the other. Every behaviour was made to fail first; dropping the read-error guard turns two tests red. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: t <t@example.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Author
|
Looks like these dependencies are updatable in another way, so this is no longer needed. |
dependabot
Bot
deleted the
dependabot/github_actions/github-actions-61c32fecf9
branch
August 18, 2026 18:16
|
🤖 Finished Retro · ✅ Success · Started 6:20 PM UTC · Completed 6:28 PM UTC Commit: |
Retro: PR #3212 — Dependabot auto-closed, zero agent interactionPR: #3212 — What happenedDependabot opened PR #3212 on 2026-08-10 to bump 6 GitHub Actions dependencies ( The PR sat for 8 days with no human review and no agent involvement — the AssessmentThis retro run is a pure token waste: a bot-authored, auto-closed, unmerged PR with zero triage/code/review/fix agent interaction and zero human review. There is nothing to retrospect. The root cause is that the Existing issue coverageThis problem is extensively documented across 22+ open issues on
This PR provides additional evidence for those issues: another wasted retro dispatch on a zero-interaction Dependabot PR. No new proposals are warranted — all potential improvements are already tracked, and the consolidation effort (#5817) is the right next step. No proposals filedEvery improvement this retro could suggest (skip retro for bot PRs, skip retro for zero-agent-interaction PRs, skip retro for unmerged PRs, add author-type filtering to the shim workflow) is already covered by existing open issues on |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps the github-actions group with 6 updates in the / directory:
6.0.27.0.16.4.07.0.00.32.00.35.16.2.07.0.04.1.04.6.010.2.011.0.0Updates
actions/checkoutfrom 6.0.2 to 7.0.1Release notes
Sourced from actions/checkout's releases.
Changelog
Sourced from actions/checkout's changelog.
... (truncated)
Commits
3d3c42eprep v7.0.1 release (#2531)2880268escape values passed to --unset (#2530)12cd223trim only ascii whitespace for branch (#2521)62661c4skip running unsafe pr check if input is default (#2518)e8d4307Bump the minor-actions-dependencies group with 2 updates (#2499)631c942eslint 9 (#2474)4f1f4aeBump actions/upload-artifact from 4 to 7 (#2476)ba09753Bump actions/checkout from 6 to 7 (#2488)b9e0990Bump docker/login-action from 3.3.0 to 4.2.0 (#2479)e8cb398Bump docker/build-push-action from 6.5.0 to 7.2.0 (#2478)Updates
actions/setup-nodefrom 6.4.0 to 7.0.0Release notes
Sourced from actions/setup-node's releases.
Commits
8207627Migrate to ESM and upgrade dependencies (#1574)04be95cAdd cache-primary-key and cache-matched-key as outputs (#1577)7c2c68ddocs: Update caching recommendations to mitigate cache poisoning risks (#1567)6a61c03Merge pull request #1569 from jasongin/update-actions-cache-5.1.030eb73bResolve high-severity audit issues4e1a87aUpdate dist360237fStrict equality4f8aac5Bump@actions/cacheto 5.1.0, log cache write deniedf4a67bbOnly usemirrorTokeningetManifestif it's provided (#1548)0355742Remove dummy NODE_AUTH_TOKEN export (#1558)Updates
fullsend-ai/fullsend/.github/workflows/reusable-dispatch.ymlfrom 0.32.0 to 0.35.1Release notes
Sourced from fullsend-ai/fullsend/.github/workflows/reusable-dispatch.yml's releases.
... (truncated)
Commits
19b3583Merge pull request #6008 from fullsend-ai/agent/6005-extend-triage-dispatch-p...be87fe5Merge pull request #5921 from fullsend-ai/renovate/registry.access.redhat.com...0896d20ci(#6005): extend triage dispatch polling to 120sf398f78Merge pull request #5578 from fullsend-ai/fix-5575-dispatch-pr-checke0d8a20Merge pull request #5992 from fullsend-ai/test-5987-branch-namespace14867d7fix(#5575): drop issues: read resurrected by rebase in org-mode dispatchd0dfce4Merge pull request #5999 from AshwinUgale/docs/testing-agents-significance9a86f59Merge branch 'main' into docs/testing-agents-significance133ae91docs(#5575): document org-mode fail-open of the linked-PR guard9f9a9cafix(#5575): match linked-PR closing keywords instead of substring searchUpdates
actions/setup-pythonfrom 6.2.0 to 7.0.0Release notes
Sourced from actions/setup-python's releases.
Commits
5fda3b9Pin SHA commits and update docs with latest versions (#1338)4ab7e95Merge pull request #1337 from actions/philip-gai/bump-actions-cache-6-2-00f3a009Remove the pip-install input (#1336)f8cf429Migrate to ESM and upgrade dependencies (#1330)54baeeaValidate and retry manifest fetch to prevent silent failures (#1332)c709277Annotation code fix (#1335)6849080remove EOL Python versions and Bumps numpy text fixture (#1333)0903b46Bump certifi from 2020.6.20 to 2024.7.4 in /tests/data (#1328)ece7cb0Fix pip cache error handling on Windows. (#1040)1d18d7aUpdate advanced-usage.md (#811)Updates
docker/login-actionfrom 4.1.0 to 4.6.0Release notes
Sourced from docker/login-action's releases.
... (truncated)
Commits
dbcb813Merge pull request #1051 from docker/dependabot/npm_and_yarn/aws-sdk-dependen...5bcb015[dependabot skip] chore: update generated contentb30b2f2build(deps): bump the aws-sdk-dependencies group across 1 directory with 2 up...9087f1eMerge pull request #1057 from docker/dependabot/npm_and_yarn/js-yaml-5.2.20009830[dependabot skip] chore: update generated content2325523build(deps): bump js-yaml from 5.2.1 to 5.2.24ec1d4aMerge pull request #1056 from docker/dependabot/npm_and_yarn/postcss-8.5.225fc99baMerge pull request #1053 from docker/dependabot/github_actions/aws-actions/co...e512bd5Merge pull request #1052 from docker/dependabot/github_actions/codeql-actions...a146c91Merge pull request #1059 from crazy-max/harden-buildx-scope-pathsUpdates
actions/stalefrom 10.2.0 to 11.0.0Release notes
Sourced from actions/stale's releases.
Commits
4391f3dFix 24 high severity vulnerabilities by overriding brace-expansion to 5.0.8 (...eaf9131refactor: update imports to use ES module syntax and improve test structure (...1e223dbBump undici to 6.27.0 via override, clean up stale license files, and version...9461cb1fix:only-issue-typesdoes not affect PRs (#1338)eb5cf3achore: upgrade dependencies and bump version to 10.3.0 (#1335)db5d06aEnhancement: ignore stale labeling events (#1311)