Model Registry: Register New Version form

[mturley]

Closes RHOAIENG-7571

Description

Implements the "Register New Version" button in these places:

• RegisteredModelsTableToolbar (no specific registered model)
• ModelVersionListView empty state (under a specific registered model)
• ModelVersionListView toolbar (under a specific registered model)

Depending on where the action was selected, the user will be redirected to one of these routes which both render the RegisterVersion page:

• /modelRegistry/{mrName}/registerVersion - Presents a typeahead select for choosing a model
• /modelRegistry/{mrName}/registeredModels/{registeredModelId}/registerVersion - Pre-selects the model and disables the model field

The RegisterVersion form is mostly a subset of the RegisterModel form - Version Details and Model Location fields in both are factored out into a new component RegistrationCommonFormSections. The only difference is that instead of entering a model name and description we let the user select a model (or preselect it for them), and then we show some help text and prefill some fields based on the selected model.

When a model is selected, the hook usePrefillRegisterVersionFields re-renders with a new registeredModel value which causes it to fetch the versions of that model, then fetch the artifacts for that version, finally deriving a latestVersion and latestArtifact. The useEffect in that hook is then triggered to update form values based on latestArtifact (source model format/version and model location endpoint/bucket/region), and latestVersion is returned and passed into RegistrationCommonFormSections where it is used to show the "Current version is ..." help text.

If the model selection changes and the selected model has no version/artifact, nothing will be prefilled. If it has a version and artifact but the URI on that artifact is malformed (cannot be parsed into endpoint/bucket/region), only the source model format/version is prefilled. Any fields that can't be prefilled are reset to empty, so switching between models should not leave behind values prefilled from another model.

Registering a new version from the registered models table (no preselected model):

Selecting a model prefills fields:

Registering a new version from a registered model's page (when there are no versions):

Registering a new version from a registered model's page (when there are already versions):

Model is preselected and fields are already filled:

cc @yih-wang

How Has This Been Tested?

Tested on modelregistry-ui cluster. Tried registering versions by reaching the form from all 3 buttons, covered all cases described above re: prefilling.

Test Impact

Unit tests added for new getLastCreatedItem util, and tests moved for utils that moved (filterArchiveVersions, filterLiveVersions).

Cypress tests added to cover all cases of prefilling/clearing behavior, form validation, and creating expected resources on submit in each case.

Request review criteria:

Self checklist (all need to be checked):

• The developer has manually tested the changes and verified that the changes work
• 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 or cypress tests 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.

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

[manaswinidas]

When I'm trying to Register new version via dropdown menu in the Registered models table.. after selecting model name.. the model location fields are pre-filled but in case of Register new version button in the Versions table ... although the model name is prefilled, the model location fields aren't pre-filled, is this expected?

[mturley]

nope, that is not expected... thanks, good catch.

[yih-wang]

Thanks for all the work @mturley! The only comment I have is regarding the visual style of the read-only fields (model registry and model name). I know you are following the mockup to use the read-only status for a text field. But recently I just noticed the other forms are using plain text to show the read-only values. See the image below. I think we should follow that consistency. I'm fine to either address it in this issue or leave it to post-mvp. Sorry for the duplicated work!

[manaswinidas]

The registration and auto-fill work fine now. But after a successful model version registration the redirect URL should be the Model version table(according to mocks). This was there earlier AFAIR. It's going to the version Details page for me. Let me know if I'm not referring to the latest mocks.

[mturley]

@manaswinidas good catch, I've rebased and fixed that. I had to squash the commits to avoid a bunch of pain in rebasing on top of #3084, sorry if that makes it harder to re-review -- mostly I moved that PR's changes to RegisterModel into RegistrationCommonFormSections.

@yih-wang no worries! yeah, do you mind including that somewhere we're tracking post-MVP refactors? I'm not sure the best place for it for now - we need to meet and follow up to make sure there are ENG issues opened for all those under https://issues.redhat.com/browse/RHOAIENG-10405 at some point soon.

[gitdallas]

could combine these to 2 by passing ModelState or even to 1 if you didn't mind doing models: ModelVersion[] | RegisteredModel[], doesn't matter though

[gitdallas]

i see these were just moved from another place anyway 😆

[mturley]

Yeah 😆 that's fair.. probably better to factor them out using generics or use ModelRegistryBase, but that's tech debt for another time I think (or fine as-is if we never get to it)

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

Approval requirements bypassed by manually added approval.

This pull-request has been approved by: gitdallas

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:

• frontend/OWNERS

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

[yih-wang]

@yih-wang no worries! yeah, do you mind including that somewhere we're tracking post-MVP refactors? I'm not sure the best place for it for now - we need to meet and follow up to make sure there are ENG issues opened for all those under https://issues.redhat.com/browse/RHOAIENG-10405 at some point soon.

Add a ux issue RHOAIUX-317 to track the following work