tech-insights: ability to add filters on the checks#6697
tech-insights: ability to add filters on the checks#6697kurtaking merged 15 commits intobackstage:mainfrom
Conversation
Changed Packages
|
cf031e1 to
d16ac69
Compare
...ghts-backend-module-jsonfc/src/module/techInsightsModuleJsonRulesEngineFactCheckerFactory.ts
Outdated
Show resolved
Hide resolved
e9054bb to
d4ab081
Compare
...sights/plugins/tech-insights-backend-module-jsonfc/src/service/JsonRulesEngineFactChecker.ts
Show resolved
Hide resolved
57a994d to
2a73106
Compare
PatrickFrueh
left a comment
There was a problem hiding this comment.
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!
|
@surajnarwade, I see dependency updates, along with other updates now. Assuming that's to make CI happy? It would be better if the plugin owners would upgrade to latest version of backstage and solve node24 issues outside of this feature request. |
|
@surajnarwade, the Tech insights version bump to |
2a73106 to
a8ca195
Compare
|
@kurtaking @awanlin thank you so much for the comments 🙏 I have rebased my PR, can you please review again :) |
workspaces/tech-insights/plugins/tech-insights-common/src/types/checks.ts
Show resolved
Hide resolved
Earlier I tried this in my other PR: backstage#6697 but to make that PR smaller and easier to review I have raised this separate PR to upgrade typescript version. This PR upgrades typescript version and updates respective api report and knip report. once this is merged, I will rebase my other PR. Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk>
|
I have added typescript version in separate PR: #6956 once its merged. I will rebase this current PR so hopefully it's easy to review :) |
There was a problem hiding this comment.
Pull request overview
This PR adds the ability to filter tech-insights checks based on entity criteria, addressing issue #4259. The feature allows users to selectively apply checks only to entities that match specific filter conditions (e.g., only production components, only APIs, etc.), improving flexibility and reducing unnecessary check executions.
Changes:
- Added optional
filterproperty to theCheckinterface supporting entity property matching with dot notation for nested fields - Implemented filter evaluation logic with case-insensitive string comparison and support for OR/AND logic
- Integrated catalog service to fetch entity metadata for filter matching with graceful fallback when unavailable
- Added comprehensive test coverage for various filter scenarios including edge cases
Reviewed changes
Copilot reviewed 12 out of 13 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| workspaces/tech-insights/plugins/tech-insights-common/src/types/checks.ts | Added optional filter property to Check interface type definition |
| workspaces/tech-insights/plugins/tech-insights-common/report.api.md | Updated API report with new filter property |
| workspaces/tech-insights/plugins/tech-insights-backend-module-jsonfc/src/service/config.ts | Added filter reading logic from configuration |
| workspaces/tech-insights/plugins/tech-insights-backend-module-jsonfc/src/service/JsonRulesEngineFactChecker.ts | Implemented filter matching logic with catalog integration and fallback behavior |
| workspaces/tech-insights/plugins/tech-insights-backend-module-jsonfc/src/service/JsonRulesEngineFactChecker.test.ts | Added comprehensive test coverage for filter functionality |
| workspaces/tech-insights/plugins/tech-insights-backend-module-jsonfc/src/module/techInsightsModuleJsonRulesEngineFactCheckerFactory.ts | Injected catalog and auth services into module |
| workspaces/tech-insights/plugins/tech-insights-backend-module-jsonfc/package.json | Added required dependencies for catalog integration |
| workspaces/tech-insights/plugins/tech-insights-backend-module-jsonfc/README.md | Documented filter feature with usage examples |
| workspaces/tech-insights/packages/backend/src/index.ts | Updated example backend to include catalog and auth services |
| workspaces/tech-insights/packages/backend/package.json | Added catalog-node dependency |
| workspaces/tech-insights/.changeset/brave-radios-breathe.md | Added changeset documenting the feature |
| workspaces/tech-insights/yarn.lock | Updated lockfile with new dependencies |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
workspaces/tech-insights/plugins/tech-insights-backend-module-jsonfc/README.md
Show resolved
Hide resolved
workspaces/tech-insights/plugins/tech-insights-common/src/types/checks.ts
Show resolved
Hide resolved
workspaces/tech-insights/plugins/tech-insights-backend-module-jsonfc/src/service/config.ts
Show resolved
Hide resolved
...sights/plugins/tech-insights-backend-module-jsonfc/src/service/JsonRulesEngineFactChecker.ts
Show resolved
Hide resolved
...sights/plugins/tech-insights-backend-module-jsonfc/src/service/JsonRulesEngineFactChecker.ts
Show resolved
Hide resolved
| operator: equal | ||
| value: true | ||
| ``` | ||
|
|
There was a problem hiding this comment.
The filter documentation should explain the fallback behavior when the catalog service is unavailable. Currently, if catalog/auth services are not provided or entity fetch fails, all checks run without filtering. This is a sensible fallback but should be documented so users understand the behavior and don't assume checks are being filtered when they aren't.
Consider adding a note like: "Note: If the catalog service is unavailable, checks with filters will run against all entities as a fallback to ensure checks continue to function."
| > Note: If the catalog (or auth) service is unavailable, or if entity fetching fails, checks that are configured with filters will run against all entities as a fallback to ensure checks continue to function. In this scenario, no filtering is applied. |
There was a problem hiding this comment.
I have updated the README :)
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 12 out of 13 changed files in this pull request and generated 3 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
workspaces/tech-insights/plugins/tech-insights-backend-module-jsonfc/src/service/config.ts
Show resolved
Hide resolved
...sights/plugins/tech-insights-backend-module-jsonfc/src/service/JsonRulesEngineFactChecker.ts
Show resolved
Hide resolved
...s/plugins/tech-insights-backend-module-jsonfc/src/service/JsonRulesEngineFactChecker.test.ts
Show resolved
Hide resolved
| // Only fetch entity from catalog if there are checks with filter criteria | ||
| // This optimization avoids unnecessary catalog API calls | ||
| if (checksWithFilters.length > 0) { | ||
| const catalogEntity = await this.fetchEntityFromCatalog(entity); |
There was a problem hiding this comment.
We should be able to simplify this quite a bit if we, instead of getting the entity by ref, get entities based on the filter and assert that the entity is found. That would move the filtering logic to match whatever catalog does and would be automatically receiving the updates if the catalog filtering logic changes. I think this is good enough for now though
There was a problem hiding this comment.
do you mean instead of using:
this.catalog.getEntityByRef
I should use this, provide filter argument, instead of implementing filter logic ourselves?
this.catalog.getEntities
There was a problem hiding this comment.
That would be though process here. There are downsides on both approaches (DB load <> maintainability) I don't know if Backstage currently exposes the filtering logic for this kind of reverse entity filtering that you constructed but if it that is available in a public library, that could be a case. Either way, if you add the test cases and modify your reverse entity filter implementation to match what is documented here: https://backstage.io/docs/features/software-catalog/catalog-customization/#entity-filters we should be golden.
There was a problem hiding this comment.
I had a chat with @kurtaking previously on this PR (link to chat) regarding the predicate based filtering. I think there's PR upstream: backstage/backstage#32282 for the same.
I think we can go ahead with current implementation for now and then update the filtering once upstream one is merged?
current link which you had linked is only available in the frontend atm?
| }, | ||
| }, | ||
| ], | ||
|
|
There was a problem hiding this comment.
Can you add test cases for annotation value matching, "contains annotation" (value doesn't matter), and the negative cases ($not, $all etc.)
There was a problem hiding this comment.
sure thing, I will add more test cases, thank you :)
There was a problem hiding this comment.
these new tests would be for the predicate based filtering right?
Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk>
Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk>
Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk>
Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk>
Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk>
Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk>
Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk>
Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk>
Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk>
Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk>
Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk>
Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk>
17f9ddf to
44d18e8
Compare
Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk>
Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk>
Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk>
|
Hi @Xantier @kurtaking I have added annotations related tests and as discussed earlier, we can skip the predicate based filtering for now :) |
* tech-insights: ability to add filters on the checks Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk> * auth & catalog should not be optional Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk> * pass filtered checks array to ruleEngineResultsToCheckResponse Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk> * update the test Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk> * update api report Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk> * remove unnecessary code Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk> * update changeset Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk> * make auth and catalog optional Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk> * update report and add test Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk> * update tests Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk> * remove commented test Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk> * update README.md Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk> * update lockfile Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk> * update dependencies to use backstage versions Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk> * add annotations related tests Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk> --------- Signed-off-by: surajnarwade <suraj.narwade@mettle.co.uk>
This PR solves this issue: #4259
Hey, I just made a Pull Request!
✔️ Checklist
Signed-off-byline in the message. (more info)