tech-insights: ability to add filters on the checks

[surajnarwade]

This PR solves this issue: #4259

Hey, I just made a Pull Request!

✔️ Checklist

• A changeset describing the change and affected packages. (more info)
• Added or updated documentation
• Tests for new functionality and regression tests for bug fixes
• Screenshots attached (for UI changes)
• All your commits have a Signed-off-by line in the message. (more info)

[backstage-goalie]

Missing Changesets

The following package(s) are changed by this PR but do not have a changeset:

• @backstage-community/plugin-tech-insights-backend
• @backstage-community/plugin-tech-insights-maturity-common
• @backstage-community/plugin-tech-insights-maturity
• @backstage-community/plugin-tech-insights-react
• @backstage-community/plugin-tech-insights

See CONTRIBUTING.md for more information about how to add changesets.

Changed Packages

Package Name	Package Path	Changeset Bump	Current Version
app	workspaces/tech-insights/packages/app	none	v0.0.11
backend	workspaces/tech-insights/packages/backend	none	v0.0.11
@backstage-community/plugin-tech-insights-backend-module-jsonfc	workspaces/tech-insights/plugins/tech-insights-backend-module-jsonfc	patch	v0.6.1
@backstage-community/plugin-tech-insights-backend	workspaces/tech-insights/plugins/tech-insights-backend	none	v2.4.3
@backstage-community/plugin-tech-insights-common	workspaces/tech-insights/plugins/tech-insights-common	patch	v0.7.1
@backstage-community/plugin-tech-insights-maturity-common	workspaces/tech-insights/plugins/tech-insights-maturity-common	none	v0.3.1
@backstage-community/plugin-tech-insights-maturity	workspaces/tech-insights/plugins/tech-insights-maturity	none	v0.5.0
@backstage-community/plugin-tech-insights-react	workspaces/tech-insights/plugins/tech-insights-react	none	v1.2.1
@backstage-community/plugin-tech-insights	workspaces/tech-insights/plugins/tech-insights	none	v0.6.2

[kurtaking]

A better route is having the module define catalog as a dependency with catalogServiceRef from @backstage/plugin-catalog-node. This is the newer way of communicating with the catalog as it includes auth support. In this scenario, I think passing { credentials: await this.auth.getOwnServiceCredentials() } as the second argument to the catalog api calls would suffice.

deps: {
  config: coreServices.rootConfig,
  logger: coreServices.logger,
-  discovery: coreServices.discovery,
+ catalog: catalogServiceRef,
+ auth: coreServices.auth,
  techInsights: techInsightsFactCheckerFactoryExtensionPoint,
}

wdyt?

[surajnarwade]

I thought it's discouraged: https://backstage.io/docs/features/software-catalog/faq/#can-i-call-the-catalog-itself-from-inside-a-processor--provider 🤔

[kurtaking]

That is referring to the ingestion and processing of entities in the catalog, known as EntityProvider and EntityProcessor. This factory class is neither a catalog provider or processor.

[surajnarwade]

ah okay, now it make sense. sorry I misunderstood earlier. I now found the similar references:

• community-plugins/workspaces/lighthouse/plugins/lighthouse-backend/src/service/EntitiesLoader.ts

  Line 32 in a872eb7

  const { token } = await auth.getPluginRequestToken({

• community-plugins/workspaces/lighthouse/plugins/lighthouse-backend/src/plugin.ts

  Line 35 in a872eb7

  catalogClient: catalogServiceRef,

I will update my code accordingly, thank you for the review.

[surajnarwade]

Hi @kurtaking, once again, thank you for the review, I have updated as per your suggestion.

[PatrickFrueh]

This feature looks great for scalar properties like kind, spec.type, spec.lifecycle, etc.
Our main use case is to drive check applicability off catalog tags, e.g.:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: cloud-ui-common
  tags:
    - cloudui
    - angular
    - common

Ideally we’d configure a check like:

filter:
  metadata.tags:
    - cloudui
    - backend

If I’m reading the current compareValues logic correctly, get(entity, 'metadata.tags') returns a string[], and the comparison ends up being ['cloudui', 'angular', 'common'] === 'cloudui', so the filter never matches.

Would you be open to extending compareValues to treat array entity values as “contains any of these filter values”? For example:

    // If entityValue is an array, treat it as "contains" semantics               <--- Suggested addition
    if (Array.isArray(entityValue)) {
      return entityValue.some(ev => this.compareValues(ev, filterValue));
    }

    // Handle string comparison case-insensitively for kind, type, lifecycle, etc.
    // This provides a better user experience as these values are typically case-insensitive
    if (typeof entityValue === 'string' && typeof filterValue === 'string') {
      return entityValue.toLowerCase() === filterValue.toLowerCase();
    }

    // Handle symbol comparison (less common but supported for completeness)
    if (typeof filterValue === 'symbol') {
      return entityValue === filterValue;
    }

    // Default to strict equality for all other types (numbers, booleans, etc.)
    return entityValue === filterValue;

That would allow metadata.tags to scope checks.

[surajnarwade]

Hi @PatrickFrueh, thank you so much for the review. I will test out the code for tags as well and make any necessary changes 🙏

[surajnarwade]

@PatrickFrueh I have updated the PR with suggested changes and tested locally and it works 🎉

[PatrickFrueh]

Thanks so much for the quick turnaround @surajnarwade. Really appreciate you testing this locally and incorporating the change. 🚀

[PatrickFrueh]

Solved from the tag-filtering use-case perspective. The changes in src/service/JsonRulesEngineFactChecker.ts:L181-184 correctly handle array values via contains semantics. LGTM 👍

Thanks again for the quick update!