fix(ui): Delete the pipeline along with its all versions. Fixes #11665

[milinddethe15]

Description of your changes:
fixes #11665
It deletes all the versions of pipeline before deleting the pipeline and shows a warning message to user.

Checklist:

• You have signed off your commits
• The title for your pull request (PR) should follow our title convention. Learn more about the pull request title convention used in this repository.

Demo:

2025-03-13.00-09-26.mp4

[google-oss-prow]

Hi @milinddethe15. Thanks for your PR.

I'm waiting for a kubeflow member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign zijianjoy for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found 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

[juliusvonkohout]

/ok-to-test

@hbelmiro

[milinddethe15]

/retest

[milinddethe15]

/retest

[milinddethe15]

/retest

[juliusvonkohout]

For me it is a
/lgtm

since it is a common bug users encounter.

But @hbelmiro and @HumairAK should approve the coding style and tests.

/hold

[hbelmiro]

@milinddethe15 The frontend is supposed to contain only UI logic.
Removing pipeline versions when a pipeline has versions is a business logic, which should be handled by the backend. Like:
Frontend: Sends deletePipeline
Backend: Checks if that pipeline has more than one pipeline version. If so, returns an error
Frontend: Handles the error by asking the user if the pipeline versions should also be deleted. If so, send to the backend a deletePipelineAndVersions
Backend: Iterates over all versions deleting them and then deletes the pipeline

[hbelmiro]

/lgtm cancel

[milinddethe15]

Got it.
So, to handle this case in server, we need to create a new API, like deletePipelineAndVersions , to delete pipeline and its versions. Since deletePipeline gives error if the pipeline has pipeline versions:

pipelines/frontend/src/apisv2beta1/pipeline/api.ts

Lines 436 to 441 in 11e84d0

	* @summary Deletes an empty pipeline by ID. Returns error if the pipeline has pipeline versions.
	* @param {string} pipeline_id Required input. ID of the pipeline to be deleted.
	* @param {*} [options] Override http request option.
	* @throws {RequiredError}
	*/
	deletePipeline(pipeline_id: string, options: any = {}): FetchArgs {

PS: Here, I wanted to ultize the existing APIs to do the job without a new API.

[hbelmiro]

Got it. So, to handle this case in server, we need to create a new API, like deletePipelineAndVersions , to delete pipeline and its versions. Since deletePipeline gives error if the pipeline has pipeline versions:

pipelines/frontend/src/apisv2beta1/pipeline/api.ts

Lines 436 to 441 in 11e84d0

	* @summary Deletes an empty pipeline by ID. Returns error if the pipeline has pipeline versions.
	* @param {string} pipeline_id Required input. ID of the pipeline to be deleted.
	* @param {*} [options] Override http request option.
	* @throws {RequiredError}
	*/
	deletePipeline(pipeline_id: string, options: any = {}): FetchArgs {

PS: Here, I wanted to ultize the existing APIs to do the job without a new API.

IMO we should create the new API or add a new parameter (default false) to the existing one that tells whether the deletion should cascade.
@HumairAK @mprahl thoughts?

[milinddethe15]

IMO we should create the new API or add a new parameter (default false) to the existing one that tells whether the deletion should cascade.

I am working on to add new parameter. but I am not sure whether to include the changes in v1beta1 APIs as well? Do we still support the v1?

@hbelmiro @HumairAK

[milinddethe15]

Hm.. Frontend is using v1beta1
is v2beta1 still in development?

[juliusvonkohout]

IMO we should create the new API or add a new parameter (default false) to the existing one that tells whether the deletion should cascade.

I am working on to add new parameter. but I am not sure whether to include the changes in v1beta1 APIs as well? Do we still support the v1?

@hbelmiro @HumairAK

Yes, right now v1 pipelines are still supported. Probably until end of 2026 and until we find a solution for ml-metadata we need v1.

[HumairAK]

hey @milinddethe15 - just wondering where are with this, are you still able to continue work on this address the above changes? if so let us know and feel free to ping me on slack to help get this in! appreciate your effort here, thanks!

[milinddethe15]

I remember working on apiserver (grpc backend), which gave me server timeouts for /delete-pipeline endpoint. I was sure I made all right code changes but wasn't able to debug 🥲. Will see if I still have the code and ping you @HumairAK, if needed.

[milinddethe15]

/close
in favour of #12019

[google-oss-prow]

@milinddethe15: Closed this PR.

In response to this:

/close
in favour of #12019

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.