Fix catalog source preview: pass yamlCatalogPath as a fallback in case yaml content is missing (default sources), pass type-specific properties under properties sub-object

[mturley]

Description

🤖 Description written in part by Claude Code

This PR adds support for tracking and using the yamlCatalogPath (the ConfigMap key where YAML catalog data is stored) in addition to the YAML content itself. This enables us to preview default catalog sources which don't have their YAML content embedded in the configmap by passing the yamlCatalogPath the API can use to look up the existing yaml.

Edit: Related bug fix: the preview request also wasn't passing source-type-specific properties (allowedOrganization, apiKey, yamlCatalogPath) under a "properties" sub-object as required.

Backend Changes (BFF)

Model Updates

• Added YamlCatalogPath *string field to CatalogSourceConfig type

API Behavior

• GetCatalogSourceConfig: Now returns yamlCatalogPath along with YAML content when fetching individual source configs
• CreateCatalogSourcePreview: Updated to accept either:
  • yaml content as a multipart form file (for new sources or when YAML is modified), OR
  • yamlCatalogPath in the config JSON (for existing sources where YAML hasn't changed)
  • Returns an error if neither is provided for YAML-type sources
• CreateCatalogSourcePreview: Also updated to fix a related bug:
  • Properly nest allowedOrganization, apiKey, and yamlCatalogPath under a .properties sub-object when constructing the config JSON sent to the catalog service

Other Improvements

• Updated warning log to only trigger for non-default sources when YAML content is missing from ConfigMap
• Added comprehensive test coverage for new preview behavior scenarios

Frontend Changes

Type System

• Added yamlCatalogPath?: string to YamlCatalogSourceConfig interface
• Updated documentation to clarify both fields are populated on GET (by ID) requests only

Component Updates

• transformFormDataToConfig: Now accepts optional existingSourceConfig parameter and preserves yamlCatalogPath from existing configs
• ManageSourceForm: Updated preview requests to include both yaml and yamlCatalogPath properties
• Component Refactoring: Simplified prop passing by moving catalogSourceConfigToFormData call into ManageSourceForm, eliminating redundant existingData prop

Testing

• Added new test cases for:
  • Preview with yamlCatalogPath only
  • Preview with empty yaml falling back to yamlCatalogPath
  • Error handling when both are missing
  • Preserving yamlCatalogPath through form transformations

Migration Notes

This is a backward-compatible change:

• Existing preview requests with yaml content will continue to work
• New preview requests can use yamlCatalogPath as a fallback
• The catalog service is expected to handle both scenarios

How Has This Been Tested?

Tested mock mode continues to work, and locally synced changes to ODH to test against production downstream catalog service

Merge criteria:

• All the commits have been signed-off (To pass the DCO check)

• The commits have meaningful messages
• Automated tests are provided as part of the PR for major new functionalities; testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
• The developer has manually tested the changes and verified that the changes work.
• Code changes follow the kubeflow contribution guidelines.
• For first time contributors: Please reach out to the Reviewers to ensure all tests are being run, ensuring the label ok-to-test has been added to the PR.

If you have UI changes

• The developer has added tests or explained why testing cannot be added.
• Included any necessary screenshots or gifs if it was a UI change.
• Verify that UI/UX changes conform the UX guidelines for Kubeflow.

[mturley]

/assign @ederign @ppadti
Claude helped me with some golang here, would be good to get a review on those parts from proper go devs

[ppadti]

Tested this with cluster, works fine.
just a minor comment

[ppadti]

As we are not using this CreateSampleCatalogSource we can remove this...

[ederign]

@mturley, can you do the minor cleanup that @ppadti suggested? I'm fine also doing it in another PR. Please let me know when it's ready!

[mturley]

@ederign @ppadti I rebased and addressed the comment

[ederign]

Thank you Mike!

[ederign]

/approve
/lgtm

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ederign

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• clients/ui/OWNERS [ederign]

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