feat: Added retention command

[rizul2108]

Description

Fixes #183
This PR continues the work started by @Althaf66 in #184.

Changes and Fixes:

Incorporating changes suggested by @bupd

Related Issue: goharbor/harbor#21783

[rizul2108]

rizul@rizu:~/OSS/harbor-cli$ ./harbor-cli tag retention create
INFO[0036] Added Tag Retention Rule                     

rizul@rizu:~/OSS/harbor-cli$ ./harbor-cli tag retention list --project-name asdfghj
┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│  ID             Action         Disabled       Params                    Priority       Scope Selectors                    Tag Selectors                      Template             │
│ ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── │
│  0              retain         false          latestPushedK: 2,         0              repository: [{repoMatches   **}]   &{matches {"untagged":true}  **}   latestPushedK        │
└───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

rizul@rizu:~/OSS/harbor-cli$ ./harbor-cli tag retention delete 
INFO[0010] retention rule deleted successfully          
INFO[0010] Retention Policy deleted successfully        

all 3 are happening smoothly

[rizul2108]

BUG: Inconsistent behavior from Harbor API after deleting a retention policy.

• Created a project asdfghj, added a tag retention rule, and deleted it using harbor-cli.
• After deletion, one of the APIs correctly reflects the deletion by not showing the retention ID in the project's metadata.
• However, other APIs still return the retention ID of the deleted policy, causing errors when handling projects with deleted retention policies.

This is error from harbor API side I think.

[Vad1mo]

BUG: Inconsistent behavior from Harbor API after deleting a retention policy.

• Created a project asdfghj, added a tag retention rule, and deleted it using harbor-cli.
• After deletion, one of the APIs correctly reflects the deletion by not showing the retention ID in the project's metadata.
• However, other APIs still return the retention ID of the deleted policy, causing errors when handling projects with deleted retention policies.

This is error from harbor API side I think.

this seems to be a problem with upstream Harbor. I suggest creating an issue there explaining the problem and referencing it here.

[bupd]

@rizul2108 do we currently have a workaround for the tag deletion issue: goharbor/harbor#21783

[rizul2108]

No currently not should I add that ?
I can add a check for that if retentionpolicy with that ID exists or not

[bupd]

Retention tag delete fails. because of the problem with harbor. for now we should do workaround as in UI.

[rizul2108]

Currently in the UI, there's only an option to delete a single rule at a time — not the entire tag retention policy for a project.
That’s why there's no issue on the UI side regarding policy-level deletion.

Given this, should we update the CLI delete tag retention command to align with the UI behavior and allow deletion of only a single rule at a time, instead of deleting the entire policy in one go?

[rizul2108]

Currently in the UI, there's only an option to delete a single rule at a time — not the entire tag retention policy for a project. That’s why there's no issue on the UI side regarding policy-level deletion.

Given this, should we update the CLI delete tag retention command to align with the UI behavior and allow deletion of only a single rule at a time, instead of deleting the entire policy in one go?

@bupd is this approach correct can I move forward with this ?

[bupd]

Sure go ahead

[rizul2108]

Screencast.from.09-04-25.01.22.53.PM.IST.webm

[rizul2108]

@bupd @Vad1mo
I noticed that the rules within a retention policy do not have a unique ID field assigned — they always default to 0, as you can see in the screenshot. This makes it difficult to identify and delete a specific rule, as there's no unique identifier to distinguish them.

As a workaround, we're forced to pass the entire rule object between functions to delete a specific rule, rather than using a simple ID. While this approach works, it feels like a poor and error-prone design.

This seems like a design oversight on Harbor's side.
I'll proceed with the current workaround, but I believe this behavior should be reconsidered.

Below is the JSON data that is being rendered in the above image.

{
  "algorithm": "or",
  "id": 132,
  "rules": [
    {
      "action": "retain",
      "params": {
        "latestPushedK": 10
      },
      "scope_selectors": {
        "repository": [
          {
            "decoration": "repoMatches",
            "pattern": "**"
          }
        ]
      },
      "tag_selectors": [
        {
          "decoration": "matches",
          "extras": "{\"untagged\":true}",
          "pattern": "**"
        }
      ],
      "template": "latestPushedK"
    },
    {
      "action": "retain",
      "params": {
        "nDaysSinceLastPush": 3
      },
      "scope_selectors": {
        "repository": [
          {
            "decoration": "repoMatches",
            "kind": "doublestar",
            "pattern": "**"
          }
        ]
      },
      "tag_selectors": [
        {
          "decoration": "matches",
          "extras": "{\"untagged\":true}",
          "kind": "doublestar",
          "pattern": "**"
        }
      ],
      "template": "nDaysSinceLastPush"
    }
  ],
  "scope": {
    "level": "project",
    "ref": 1532
  },
  "trigger": {
    "kind": "Schedule",
    "settings": {
      "cron": ""
    }
  }
}