The actions/setup-node@v6.4.0 upgrade stopped auto-shimming yarn onto
PATH via corepack. The yarn-plugin test spawns yarn via Node's
child_process.spawn() which does a raw PATH lookup, causing
ENOENT failures. Adding corepack: true ensures the yarn shim is
available.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Fredrik Adelöw <freben@gmail.com>
* docs: add backend.startup configuration documentation
Add a new 'Startup Configuration' section at the bottom of the
building-backends guide documenting the backend.startup config block.
- Explains onPluginBootFailure per-plugin control
- Explains onPluginModuleBootFailure per-module control
- Shows how to set a global default via backend.startup.default
- Includes a full YAML configuration reference
Closes#34075
Signed-off-by: ahmetoguzhanengin <ahmetoguzhanengin@gmail.com>
* docs: fix backend.startup examples per Copilot review
- Replace 'githubEntityProvider' with 'github' (the actual moduleId)
as declared in createBackendModule({ moduleId: '...' })
- Replace 'abort | continue' YAML values with 'abort # or continue'
to avoid invalid literal string interpretation
Signed-off-by: Ahmet Oğuzhan Engin <ahmetoguzhanengin@gmail.com>
Signed-off-by: ahmetoguzhanengin <ahmetoguzhanengin@gmail.com>
---------
Signed-off-by: ahmetoguzhanengin <ahmetoguzhanengin@gmail.com>
Signed-off-by: Ahmet Oğuzhan Engin <ahmetoguzhanengin@gmail.com>
PR #33936 removed duplicate dependency entries, but in two cases moved
deps from dependencies to devDependencies that are still re-exported in
the published API reports:
- @backstage/catalog-client: @backstage/plugin-catalog-common
(AnalyzeLocationRequest/AnalyzeLocationResponse types)
- @backstage/frontend-plugin-api: @backstage/config (Config type)
These need to be runtime dependencies so consumers can resolve the
types at build time.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Fredrik Adelöw <freben@gmail.com>
The field was accidentally kept from master during the rebase
conflict resolution but doesn't belong in this PR's version of
the file.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Fredrik Adelöw <freben@gmail.com>
The Azure SDK monorepo upgrade (storage-blob 12.26→12.31, identity
4.5→4.9) adds "type": "module" to package.json, making jest.mock()
unable to intercept imports from production code.
- AzureBlobStorageUrlReader: accept createContainerClient as an
optional dependency, letting tests pass a mock directly instead
of trying to mock the @azure/storage-blob module
- AzureUrlReader: provide PAT credentials in all test cases so
DefaultAzureCredential is never instantiated — the Bearer auth
flow is already covered by the integration package's own tests
- DefaultAzureDevOpsCredentialsProvider: use expect.any() for
mock instance comparison instead of new DefaultAzureCredential()
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Fredrik Adelöw <freben@gmail.com>
The stitcher parameter was removed from DefaultEntitiesCatalog's
constructor by the stitching refactor, but two tests added by the
query split PR still referenced it.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Fredrik Adelöw <freben@gmail.com>
Since protobufjs 7.5.9, the @protobufjs/inquire utility is no longer
called with dynamic module names (replaced by bundler-safe lookups in
protobufjs/protobuf.js#2254). However, webpack/rspack still statically
analyzes the inquire source and emits a "Critical dependency" warning
for its require(moduleName) pattern. This is a false positive — the
code path is dead in practice.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Fredrik Adelöw <freben@gmail.com>
Fredrik Adelöw