Conversation
|
Skipping CI for Draft Pull Request. |
|
Tag for build #723355 is 💻 For deploying this image using the dev scripts, run the following first: export MAIN_IMAGE_TAG='3.70.x-545-gd4e86e6221'🕹️ A |
| entityMenuTypes = [...baseEntityMenuTypes, ...splitComponentMenuTypes]; | ||
| } else { | ||
| entityMenuTypes = [...baseEntityMenuTypes, ...componentMenuType]; | ||
| } |
|
|
||
| export function getCurriedImageTableColumns(watchedImagesTrigger) { | ||
| export function getCurriedImageTableColumns(watchedImagesTrigger, isFeatureFlagEnabled) { | ||
| const isFrontendVMUpdatesEnabled = isFeatureFlagEnabled('ROX_FRONTEND_VM_UDPATES'); |
There was a problem hiding this comment.
Feature flagging the count link for components
| }, | ||
| [entityTypes.NODE]: { | ||
| // @TODO: Uncomment this once we're using the new entity | ||
| // children: [entityTypes.NODE_COMPONENT], |
There was a problem hiding this comment.
Open to suggestions on how to feature flag the following in entityRelationships. Since it's a separate module and outside the React lifecycle, I can't use the feature flag hook here
There was a problem hiding this comment.
As long as we feature flag the links, it may not be worth feature-flagging the direct "sub-routes" built from this map. (Re-factoring this map everywhere it is used would be a risky change.)
ce55387 to
ce1d820
Compare
6cddd70 to
efdce6e
Compare
efdce6e to
48f536d
Compare
|
Images are ready for the commit at d4e86e6. To use with deploy scripts, first |
vjwilson
left a comment
There was a problem hiding this comment.
A good foundation.
A couple of places I think we should revisit as we integrate the split CVE types, and one stylistic suggestion for tile sidebar width.
Regardless, let's merge once tests pass.
| const currentEntity = { [currentEntityType]: id }; | ||
| const newEntityContext = { ...entityContext, ...currentEntity }; | ||
|
|
||
| const entityGridContainerClassName = `${entityGridContainerBaseClassName} grid-columns-1 md:grid-columns-2 lg:grid-columns-2`; |
There was a problem hiding this comment.
Why did you switch to the other exported class and re-concatenate?
There was a problem hiding this comment.
So this is the before and after of this change
I noticed that we were only showing two columns in the component overview so it differed from the class we were using in general, which was for 3 columns. So this change will instead use the base class and then append specific classes for this view
There was a problem hiding this comment.
^ That's probably a side-effect of widening the tiles right sidebar.
I'm fine with your fix for it, but I'm afraid this may turn into whack-a-mole. Let's get UX suggestion on this. cc: @alanonthegit
There was a problem hiding this comment.
Oh no, that wasn't the issue. We're using grid columns for the overview and it was using a 3 column grid before. If you look at the first image you'll see it looks like you can add another third element to the right. It was on master as well. It's not really related to splitting the components but I just did it anyway.
| return ( | ||
| <div | ||
| className={` h-full relative border-base-100 border-l w-32 ${ | ||
| className={` h-full relative border-base-100 border-l w-43 ${ |
There was a problem hiding this comment.
Rather than making the right tile bar wider, would it be better to make long entity names wrap to two lines?
There was a problem hiding this comment.
Hmm, yea that's true. This probably wasn't the best solution. I could do two things:
- Remove the width restriction and add a max-width and wrapping
- Keep the width restriction and just add wrapping
I'll try #2 which is what you're suggesting.
There was a problem hiding this comment.
I ended up doing #1 instead. So I'll remove the w-32, add max-w-43, and add a text wrap class in case the text might be longer than that
| let queryVulnCounterFieldName = 'vulnCounter'; | ||
| let queryVulnsFieldName = 'vulns'; | ||
| let queryCVEFieldsName = 'cveFields'; | ||
| let queryFragment = VULN_CVE_LIST_FRAGMENT; |
There was a problem hiding this comment.
I was also experimenting with this file, because we will have to show all three kinds of fixable CVEs on the Cluster Overview, and choose the correct type for the other entities. We probably should have broken this down across both of these features.
For now, I'll pause my branch, until we get this version merged in, and then expand on this approach.
| const VulnMgmtNodeComponents = ({ selectedRowId, search, sort, page, data, totalResults }) => { | ||
| const query = gql` | ||
| query getComponents($query: String, $pagination: Pagination) { | ||
| results: nodeComponents(query: $query, pagination: $pagination) { | ||
| ...nodeComponentFields | ||
| } | ||
| count: nodeComponentCount(query: $query) | ||
| } | ||
| ${VULN_NODE_COMPONENT_LIST_FRAGMENT} | ||
| `; |
There was a problem hiding this comment.
I wonder if it is worth doing 2 different sets of files at this "container" level. We should compare the complexity of the single CVE list file with conditionals for the three new types of CVEs, and decide which way is better. Then we made them consistent one way or the other.
There was a problem hiding this comment.
We can try to leave this as-is for now, and come back tomorrow and make refactors so it's more consistent with your changes
|
|
||
| export const IMAGE_CVE_LIST_FRAGMENT = gql` | ||
| fragment cveFields on ImageVulnerability { | ||
| fragment imageCVEFields on ImageVulnerability { |
There was a problem hiding this comment.
I think we need to use this new name in the file ui/apps/platform/src/Containers/VulnMgmt/List/Cves/VulnMgmtListCves.js above, at line 321.
| }, | ||
| [entityTypes.NODE]: { | ||
| // @TODO: Uncomment this once we're using the new entity | ||
| // children: [entityTypes.NODE_COMPONENT], |
There was a problem hiding this comment.
As long as we feature flag the links, it may not be worth feature-flagging the direct "sub-routes" built from this map. (Re-factoring this map everywhere it is used would be a risky change.)
|
@sachaudh You're right, this is related to my stuff on not this PR. Investigating why this passed on my PR branch and not master now... :/ |
Ah, yea let me know. I don't think I can push my changes in until it's fixed. I'll try re-running |








Description
IMAGE_COMPONENTandNODE_COMPONENTentityRelationships.tsbecause that module doesn't live within the React lifecycle so I'm open to suggestions on how to go about feature flagging it. For now, I commented out the changes so the entity relationships won't be updated right nowChecklist
If any of these don't apply, please comment below.
Testing Performed