Proposal: Implementation of `purge` command

[vg006]

Overview

The Harbor CLI implemented numerous commands, integrating most of the Harbor REST APIs, and this proposal adds the purge command to that list.

Proposal

The following is the tentative structure of the harbor schedule purge command, So I request the maintainers and community to review this and share suggestions on this.

# Get details of a specific purge job
> harbor schedule purge status <purge_id>

# Stop the purge audit log execution specified by ID
> harbor schedule purge stop <purge_id>

# Get purge job logs
> harbor schedule purge logs <purge_id>

# Get purge jobs' schedule
> harbor schedule purge list

# Get purge jobs results
> harbor schedule purge history

# Create a purge job schedule
> harbor schedule purge create (--cron / -e) <cron_expression>

# Update purge's schedule
> harbor schedule purge update (--cron / -e) <cron_expression>

cc: @bupd @Vad1mo @OrlinVasilev @NucleoFusion

[bupd]

Hmm what are the subcommands that are already present you are touching on - i believe schedule is already a cmd so purge should be a subcmd rather than being a main cmd

[vg006]

Here are my genuine thoughts on the above proposed structure.

1. Yeah, but the schedule command returns a list of all the job schedules, whereas the purge schedule command is designed to be particular with purge jobs.

2. According to your opinion, we could move purge schedule to schedule root command with --purge flag, but there is not only a GET endpoint, also we have POST and PUT endpoints to update the purge job's schedule. So I genuinely feel it is not a good way to use this flag based approach.

3. And if we are going with a sub-command schedule purge, the commands related to purge jobs seems to be scattered, impacting the UX. I mean, all the purge job related actions under harbor purge, but only the purge job schedules within harbor schedule purge.

4. As we already have scan-all jobs schedule commands implemented within scan-all command. (ref) I thought of going with this design.

@bupd Hope you got the point and May I know your thoughts once again?

[bupd]

3. No

That's how it is right now, please don't change the methodology of cli it just adds undefined behaviour

Please go ahead with purge as subcmd not as a flag.

Thanks

[bupd]

3. No

That's how it is right now, please don't change the methodology of cli it just adds undefined behaviour

Please go ahead with purge as subcmd not as a flag.

Thanks