Skip to content
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

Follow up misc fixes for pipeline version feature #2352

Conversation

DaoDaoNoCode
Copy link
Member

@DaoDaoNoCode DaoDaoNoCode commented Jan 17, 2024

JIRA: https://issues.redhat.com/browse/RHOAIENG-1749

Description

This PR did the following things:

  1. Clean up the props that passes between the tables, to avoid the console warning
  2. Prevent warning when table is in loading state with disableRowRenderSupport set
  3. Remove View all runs for pipeline row
  4. When adding new versions, don't collapse the expanded pipeline row on the pipeline table
  5. Use context to hold the versions for the pipeline runs page to reduce API calls

How Has This Been Tested?

  1. Click around to make sure no console warning presents
  2. Check the changes above are addressed correctly

Test Impact

N/A, will add later.

Request review criteria:

Self checklist (all need to be checked):

  • The developer has manually tested the changes and verified that the changes work
  • Commits have been squashed into descriptive, self-contained units of work (e.g. 'WIP' and 'Implements feedback' style messages have been removed)
  • Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
  • The developer has added tests or explained why testing cannot be added (unit tests & storybook for related changes)

If you have UI changes:

  • Included any necessary screenshots or gifs if it was a UI change.
  • Included tags to the UX team if it was a UI/UX change (find relevant UX in the SMEs section).

After the PR is posted & before it merges:

  • The developer has tested their solution on a cluster by using the image produced by the PR to main


type PipelineRunDetailsVersionContextProps = {
children: React.ReactNode;
resource?: PipelineRunJobKF | PipelineRunKF | null;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Don't we only want this context used if there's a resource provided? Seems like this should be marked as required.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I need to do some refactor on the pipeline details page because the run is from const run = runResource?.run;, which could be undefined and the early exit should be checked. I will change that.

children,
resource,
}) => {
const versionRef = getPipelineVersionResourceRef(resource);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like this context is only accessed in 1 place, where this version data is needed, I'm wondering if it makes more sense to simply store the "run" object for this context and instead call it PipelineRunDetailsContext. Since I think keeping track of a run from a couple different locations is its main purpose.

@@ -85,7 +86,7 @@ const PipelineRunDetails: PipelineCoreDetailsPageComponent = ({ breadcrumbPath,
}

return (
<>
<PipelineRunDetailsVersionContextProvider resource={run}>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can limit this to wrap around PipelineRunDrawerBottomContent only since that's the only place the context seems to be used.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same goes for the PipelineRunJobDetails usage here.

const usePipelineRunVersionInfo = (
resource: PipelineRunKF | PipelineRunJobKF | null,
): {
version?: PipelineVersionKF;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we always return version and error, they're just potentially undefined/null? We only want to make props optional if they're truly optional, not just to account for undefined values.

Copy link
Contributor

@jpuzz0 jpuzz0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

Copy link
Contributor

openshift-ci bot commented Jan 18, 2024

[APPROVALNOTIFIER] This PR is APPROVED

Approval requirements bypassed by manually added approval.

This pull-request has been approved by: jpuzz0

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-bot openshift-merge-bot bot merged commit 6e090e2 into opendatahub-io:f/pipelines-enhancement Jan 18, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants