Missing test results extension#628
Conversation
Signed-off-by: Philipp Heil (zkdev) <philipp.heil@sap.com>
Co-authored-by: Heil, Philipp <philipp.heil@sap.com>
Signed-off-by: Franziska Schallhorn <franziska.schallhorn@sap.com>
zkdev
left a comment
There was a problem hiding this comment.
(providing some earlier feedback, haven't checked the entire PR yet)
| def find_artefact_with_truthy_test_policy_label(component: ocm.ComponentDescriptor) -> list[ocm.Artifact] | None: | ||
| artefacts = [] | ||
| for resource in component.component.resources: | ||
| if resource.relation == 'local': # !!WE NEED TO DISCUSS THIS IN THE TEAM! |
There was a problem hiding this comment.
thanks for bringing this up.
after a discussion with @8R0WNI3 we figured it might be best to leverage extension-cfg instead of hard coding. long-term we want to merge this into existing artefact-filter, however this currently does not include resource relation. therefore we need something extension specific. how about:
extensionCfg:
missingTestResults:
includeExternalArtefacts: <bool>for the resource type filter we can leverage the existing artefact filter
Co-authored-by: Philipp Heil <philipp.heil@sap.com> Signed-off-by: Franziska Schallhorn <franziska.schallhorn@sap.com>
| return | ||
| for label in ta.labels: | ||
| if label.name == 'gardener.cloud/test-scope': | ||
| artefacts_with_tests.append(label.value) |
There was a problem hiding this comment.
gardener.cloud/test-scope is a list in the tests, but the code does artefacts_with_tests.append(label.value), producing a list-of-lists (e.g. [['job-image-1', ...], ['job-image-2']]). wouldn’t if artefact_requiring_tests.name not in artefacts_with_tests below then be almost always True, since you’re comparing a string against inner lists? 🤔
In the past, errors in conjunction with the BDBA scan were identifiable in case the uploaded or scanned file seems to be empty (0 bytes identified). To prevent follow-up issues in that case, early-exit with an error instead if 0 bytes were identified. Signed-off-by: Jonas Brand (8R0WNI3) <j.brand@sap.com>
from 1.2725.0 to 1.2728.0
Instead of hardcoding a list of finding types for which to re-use
discovery dates, re-use them by default if the data key (i.e. their
identity) matches. This behaviour may be adjusted per finding type
(e.g. for vulnerabilities, only re-use if the package and CVE match).
Finding types can still be configured via the findings-cfg to not honour
existing discovery dates at all, e.g.:
```
- type: finding/<type>
reuse_discovery_date:
enabled: true | false
max_reuse_time: 30d
```
Signed-off-by: Jonas Brand (8R0WNI3) <j.brand@sap.com>
Since the data key is used per default now, these code paths (which also (indirectly) implemented a check against the data key) became obsolete now. Signed-off-by: Jonas Brand (8R0WNI3) <j.brand@sap.com>
Signed-off-by: Jonas Brand (8R0WNI3) <j.brand@sap.com>
Signed-off-by: Jonas Brand (8R0WNI3) <j.brand@sap.com>
from 1.2728.0 to 1.2729.0
from 0.7.0 to 0.8.0
Signed-off-by: Jonas Brand (8R0WNI3) <j.brand@sap.com>
from 1.2729.0 to 1.2730.0
|
closed in favour of non-fork PR |
|
continued here: #634 |
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Release note: