🚀 tech-insights: Ability to add filters on the checks under techInsights.factChecker

[surajnarwade]

Workspace

tech-insights

🔖 Feature description

Checks under techInsights.factChecker should be able to define filters. so that we can apply checks on required set of entities rather than all entities provided by respective factRetriever.

Example:

techInsights:
  factChecker:
    checks:
      groupOwnerCheck:
        type: json-rules-engine
        name: Group Owner Check
        description: Verifies that a group has been set as the spec.owner for this entity
        filter:                                                                     <-- This
        - component.spec.lifecycle == production.     <-- This
        factIds:
          - entityOwnershipFactRetriever
        rule:
          conditions:
            all:
              - fact: hasGroupOwner
                operator: equal
                value: true

Note: this is just an example but any other config which provides similar results will also work.

🎤 Context

In my use-case, I have a requirement where I have certain checks which will only apply to subset of entities not all entities.

✌️ Possible Implementation

No response

👀 Have you spent some time to check if this feature request has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

Are you willing to submit PR?

None

[kurtaking]

We currently store our filter for checks under the metadata prop.

techInsights:
  factChecker:
    checks:
      groupOwnerCheck:
        type: json-rules-engine
        name: Group Owner Check
        ...
      metadata:
        filter:
          kinds:
            - Component
          category:
            - catalog

However, I like this use case. I think the framework supporting check filtering is a better long-term solution.

[surajnarwade]

@kurtaking do you implement filtering in custom checker factory? do you have code reference if available ?

[kurtaking]

@kurtaking do you implement filtering in custom checker factory? do you have code reference if available ?

We've created our own module and have extended the service to support this. I'll do my best to share some code in a bit. Essentially, we call getAllChecks first, filter components based on the Check metadata, and then call runChecks, passing in the filtered check results, flattened to their ID.

[awanlin]

@Xantier @punkle any thoughts on this?

[kurtaking]

@surajnarwade - here is how we are filtering checks.

async getChecksForEntity(
  entity: Entity,
): Promise<TechInsightJsonRuleCheck[]> {
  const allChecks = await techInsights.getAllChecks();

  // we filter here based on the `metadata.kinds` field we require on each check definition
  const filteredChecks = allChecks.filter(check => {
    return (
      check.metadata?.kinds === 'all' ||
      check.metadata?.kinds?.includes(entity.kind.toLowerCase())
    );
  });

  logger.info('Filtered checks for entity', {
    entity: stringifyEntityRef(entity),
    filteredChecks: filteredChecks.length,
    totalChecks: allChecks.length,
  });

  return filteredChecks as TechInsightJsonRuleCheck[];
},

You can then pass the checkIds from the filteredChecks and pass that to techInsights.runChecks(entity, checkIds)

const techInsightChecks = await this.getChecksForEntity(entity);
const checkIds = techInsightsChecks.map(c => c.id)

const results = await techInsights.runChecks(entity, checkIds).

This whole thing requires you to override some of their default implementation, i.e., calling a custom service we have that wraps tech insights. It's working, but I still believe having this in the framework would be extremely beneficial.

---

An example check of ours - we currently filter based on entity.kind and custom categories we've defined

factChecker:
  checks:
    groupOwnerCheck:
      type: json-rules-engine
      name: Has owner
      description: Verifies a group has been set as the spec.owner
      factIds:
        - entityOwnershipFactRetriever
      metadata:
        categories:
          - catalog
        kinds: all
      rule:
        conditions:
          all:
            - fact: hasGroupOwner
              operator: equal
              value: true
      links:
        - title: Learn more
          url: https://backstage.io/docs/features/software-catalog/descriptor-format#specowner-required

[hballangan-mdsol]

We also had to extend the functionality before we figured out a workaround which is to update the FactRetriever logic to filter stored facts only the filtered components.

This is tested and working for json-fc module without modifying or extending the tech-insights plugins.

customFactRetriever.ts

// This is your entityFilter
const entityFilter = {
  kind: ['Component'],
  'spec.lifecycle': ['production', 'experimental'],
  'spec.type': ['service', 'library', 'website', 'mobile'],
};

export const customFactRetriever: FactRetriever = {
  ...,
  entityFilter,  <-- this isn't functional but good to add it here in case it gets used somewhere in the future
  handler: async ({ config, auth, discovery, logger }) => {
     // This is important. You only query and store filtered components in the fact retriever
     const { items: components } = await catalogClient.getEntities({ filter: entityFilter }, { token });  
     return... 
  },
};

So far everything is working for me using tech-insights-jsonfc and tech-insights-maturity plugin, it's just that there's no way for me to query and show it in the frontend but it's not that important.

I do hope to see a standard way to filter it within the checks itself. We used to be able to show the filters in the frontend

[awanlin]

Looking for feedback from the owners @Xantier or @punkle, is this something you are open to contributions to implement? I'm sure the community would help with this!

[Xantier]

Yup, looks like a good idea and shouldn't be too difficult to implement.

[maicaballangan]

Just want to mention again that there is an entityFilter variable in the FactRetriever so if there's a way to avoid redundancies in having to double declare it then that would be ideal.

[PatrickFrueh]

Just wanted to check in on this: filtering is a pretty big blocker for us as well. It’d be great to see this supported in the framework. We’re happy to help test or contribute where possible, but mainly wanted to highlight that this would really unlock Tech Insights for our use case. Thanks!

[BethGriggs]

Based on #4259 (comment), it looks like contributions are welcome for this 🙏🏻

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.