-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(scanner): Change logic of creating entities #309
feat(scanner): Change logic of creating entities #309
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally looks good to me.
My main question would be if we want to change the logic to directly get a list of components with it's component versions instead of looping through components and getting versions from them.
What do you think?
|
||
- Go 1.15 or later | ||
- Access to a Kubernetes cluster | ||
- Heureka system for reporting findings |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we expecting certain labels on the Kubernetes pods?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do but its configurable no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean? "expecting certain labels" should also be part of the README?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is referring back to the fact that we build support groups from certain labels / annotations on the kubernetes resources
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just a commented line I'd remove
* First commit * Wip * Revert f04feab * Wip * Wip * Wip * Wip * Wip * Wip * Change naming * Add concurrency * Add READMEs * Automatic application of license header * Fix #309 (comment) * Fix #discussion_r1808503568 * Fix #309 (comment) * Fix #309 (comment) * Automatic application of license header * Fix #309 (comment) * Refactoring * Update dependencies * Fix logic for ExtractImageInfo * Add unit tests for ExtractImageInfo * Automatic application of license header * Clean-up --------- Co-authored-by: License Bot <[email protected]> Co-authored-by: Michael Reimsbach <[email protected]>
Description
As described in Issue #279 due to performance issues we decided to change the order and also the logic how entities are created in the different scanners.
The k8s-scanner will now create
Components
andComponentVersion
objects based on the information gets from the K8s scanner.The
keppel
scanner will now fetch thetrivy
report only for available components, component versions in the DB. It will then createIssue
objects.What type of PR is this? (check all applicable)
Related Tickets & Documents
Added tests?
Added to documentation?
Checklist