Add images table for Workload CVE Image single page

[dvail]

Description

Adds initial table support to the workload cve image page.

Does not include:

• pagination
• sorting
• expandable table rows
• search filter integration

Note: this may be easier to review with GitHub's "Hide whitespace" option enabled due to some component nesting changes that make the diff look larger than it is.

TODO - For some reason this is causing either the getImageDetails or the getImageVulnerabilities graphql query to fire a second time when they both complete the initial requests
This was due to the same image.metadata subresolver in both queries, but with a different field selection in each. Moving the entire image.metadata to the initial query and passing the result down resolves this issue (and clears up a network waterfall).

Checklist

• Investigated and inspected CI test results
• Unit test and regression tests added
• Evaluated and added CHANGELOG entry if required
• Determined and documented upgrade steps
• Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.

Testing Performed

Load an image single page.

Mobile:

Test clicking one of the links in the CVE column:

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[dvail]

Current dependencies on/for this PR:

• master
  • PR Add status tabs and summary card shells to images single page. #5073
    • PR Add CVE severity and status icons to image page summary cards #5116
      • PR Add images table for Workload CVE Image single page #5175 👈
        • PR Add expandable section for image vulnerability components table #5218
    • PR Add URL string union hook to better integrate url params with Tab components #5111

This comment was auto-generated by Graphite.

[roxbot]

Images are ready for the commit at 57fa3a3.

To use with deploy scripts, first export MAIN_IMAGE_TAG=3.74.x-383-g57fa3a3469.

[dvail]

Two reasons for the explicit type annotations:

1. The backend is returning a string for severity here, instead of a GraphQL enum for the severity types. Directly accessing SeverityIcons[severity] silently returns a type of any instead of React.FC.
2. After investigating the above, I found it is technically possible for the backend to return a severity of UNKNOWN_VULNERABILITY_SEVERITY, which we don't handle on the front end, so it is possible that this component will be undefined and crash the UI if the "unknown" value makes it through somehow.

[dvail]

This table is almost identical in both the image and deployment single pages, with the exception that the image name is displayed as a column next to image components in the deployment page. The way the gql resolvers are structured make it so that we will need to do some pre-processing of the data on that page before feeding it into this table.

e.g. The query might looks something like

images {
    imageVulnerabilities {
        imageComponents {}
    }
}

so we would need to get the image metadata from the top level and pass it down to the image components to get the UI structure we need.

Mandar is looking into possible alternate queries for this, so I didn't generalize the prop type here too much in order to avoid having to change it a lot later.

[dvail]

Both of the gql queries used in this section we running into the same awkwardness:

• The query and types are defined in a higher level component that was also in charge of making the request
• Child components were passed the result data and required access to the response types
• Both components requiring the type resulted in circular import errors

The two options that came to mind were:

• Move the type down to the child component, and import both the response type and child component in the parent (awkward, since the child component wasn't making the request)
• Pull the queries out into new hooks and import the type from there

[alwayshooin]

i've been doing the former tbh but pulling out into hooks is probably the cleaner solution here

[alwayshooin]

i think technically PF conventions would have this be CVE status (https://www.patternfly.org/v4/ux-writing/capitalization)

[dvail]

Oh good catch, I'll make this change now in the next PR I'm working since CI is happy with this one as-is.

[alwayshooin]

i've been doing the former tbh but pulling out into hooks is probably the cleaner solution here