-
Notifications
You must be signed in to change notification settings - Fork 31
Containerbuild / konflux #1977
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
Containerbuild / konflux #1977
Conversation
|
Skipping CI for Draft Pull Request. |
...uild-request-processor/src/main/java/com/redhat/hacbs/container/deploy/TagDeployCommand.java
Outdated
Show resolved
Hide resolved
| } | ||
|
|
||
| // TODO: ### For container-builds, should sbom generation be delegated to the task within that? If it supports it? | ||
| private void generateBuildSbom() { |
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.
@vibe13 To discuss ; Previously JBS handled SBOM after the build - I suspect now Konflux should handle that?
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.
Mmmm no sure about Konflux handling java SBOMs. Rather, SBOMer could be used because it can generate good quality manifests. But, JBS has the capability to manifest the contaminated GAVs and contaminants, so we can think of JBS creating a skeleton SBOM to be later enriched by SBOMer. I would keep it in for now, then we will discuss with Marek and see how to design this. Good point!
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.
But, I would like to see the content of SBOMs generated by Konflux regardless. There were discussions about merging our generated SBOMs with Konflux generated ones.
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.
At the moment we don't have any way of handling / storing the sbom - this was handled by BuildVerifyCommand but as we don't have a way as far as I know in the buildah based task to access the .m2/gradle repositories (as we don't have a shared workspace) I think this now needs to be handled specifically by Konflux.
| // //{Name: WorkspaceBuildSettings, Workspace: WorkspaceBuildSettings}, | ||
| // {Name: WorkspaceSource, Workspace: WorkspaceSource}, | ||
| // //{Name: WorkspaceTls, Workspace: WorkspaceTls}, | ||
| //}, |
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.
Currently I haven't figured out how (if at all) we can pass the setting.xml/tls shared workspaces - I suspect we'll need a different approach.
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.
ok
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1977 +/- ##
============================================
+ Coverage 39.38% 39.51% +0.13%
+ Complexity 812 811 -1
============================================
Files 301 301
Lines 14040 14145 +105
Branches 1469 1467 -2
============================================
+ Hits 5529 5589 +60
- Misses 7861 7907 +46
+ Partials 650 649 -1 ☔ View full report in Codecov by Sentry. |
vibe13
left a comment
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.
I have put some more questions for the sake of my understanding but overall it makes sense to me, thanks Nick!
...ld-request-processor/src/main/java/com/redhat/hacbs/container/deploy/BuildVerifyCommand.java
Show resolved
Hide resolved
| } | ||
|
|
||
| // TODO: ### For container-builds, should sbom generation be delegated to the task within that? If it supports it? | ||
| private void generateBuildSbom() { |
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.
Mmmm no sure about Konflux handling java SBOMs. Rather, SBOMer could be used because it can generate good quality manifests. But, JBS has the capability to manifest the contaminated GAVs and contaminants, so we can think of JBS creating a skeleton SBOM to be later enriched by SBOMer. I would keep it in for now, then we will discuss with Marek and see how to design this. Good point!
...uild-request-processor/src/main/java/com/redhat/hacbs/container/deploy/TagDeployCommand.java
Outdated
Show resolved
Hide resolved
java-components/resource-model/src/main/resources/crds/jvmbuildservice.io_jbsconfigs.yaml
Show resolved
Hide resolved
| } | ||
|
|
||
| // TODO: ### For container-builds, should sbom generation be delegated to the task within that? If it supports it? | ||
| private void generateBuildSbom() { |
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.
But, I would like to see the content of SBOMs generated by Konflux regardless. There were discussions about merging our generated SBOMs with Konflux generated ones.
| // //{Name: WorkspaceBuildSettings, Workspace: WorkspaceBuildSettings}, | ||
| // {Name: WorkspaceSource, Workspace: WorkspaceSource}, | ||
| // //{Name: WorkspaceTls, Workspace: WorkspaceTls}, | ||
| //}, |
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.
ok
|
New changes are detected. LGTM label has been removed. |
2ff591a to
9d5d9c4
Compare
dc28e32 to
b94f702
Compare
a536235 to
b3ccee1
Compare
|
/retest |
1eda89f to
5ac7bec
Compare
No description provided.