Proget: delete all versions of a package via API

MaxCascone

Hi, i want to delete all versions of a package via the API. So far I have this, which makes one API call per version. Is there a way to delete all versions of a package in one shot?

# get all versions of a package name from the API
$endpointBase = 'https://proget.myCompany.com/upack/myFeed'

$epEnd = 'packages?'

$branch = 'myBranch'

$results = Invoke-WebRequest -Method GET -Uri "$endpointBase/$epEnd" | 
  ConvertFrom-Json -AsHashtable | 
    Select-Object Group, Name, Versions | 
      Where-Object { $_.Name -match $branch }

# iterate through and delete one by one
foreach ($package in $results) {
  $pkgName = $package.Name
  $group   = $package.Group

  foreach ($version in $package.Versions) {
    $pkgVers = $version
    $deleteUri = "$endpointBase/delete/$group/$pkgName/$pkgVers"

    # /upack/«feed-name»/delete/«group-name»/«package-name»/«package-version»
    try {
      Invoke-RestMethod -Method DELETE -Uri $deleteUri -Headers @{"X-ApiKey" = "redacted"}
      Write-Output "Deleted $group/$pkgName/$pkgVers"
    }
    catch {
      Write-Output "Error: $pkgName/$pkgVers`: $_"
    }
  }
}

I should add that I am doing this as the first stab at an attempt to automatically delete packages from a development feed, when the corresponding branch in github is deleted, through a webhook from GH. I'm not exactly sure how that last part's going to work. If i'm going down a wrong path here, please let me know!

stevedennis

Hi @mcascone ,

We don't have a single API method that can be used to delete all package versions from the API, but the foreach loop will do the trick!

I should add that I am doing this as the first stab at an attempt to automatically delete packages from a development feed, when the corresponding branch in github is deleted

I don't know the specifics/details of your use-case, but based on what I read, I'd recommend these guidelines:

assuming: one GitHub repository, one project, one package you want to release
use the same package name/group for all packages you create for this project, regardless of branch or development status
create your "dev" packages using a prerelease version number, that has a sort of -ci.## version (assuming you use CI to build packages)
embed the commit id and branch in your upack metadata file, for traceability
if you want to see which branch the packages was created from using the version number alone, add a +branch metadata label to the version number for branches (don't do this for master)
use repackaging and promotion to take your -ci packages to -rc to stable (and the desired feed)
let retention policies automatically cleanup up the -ci packages

MaxCascone

@stevedennis thank you very much for the quick reply!

I agree that there’s a smell to some of the process I’ve set up.

The gist of the problem I’ve tried to solve is: how can I guarantee that a deploy of a given branch will always get its latest build (unless a specific version is provided) from the development feed, if there are multiple feature branches in development at the same time, pushing to the same feed?

What I do now is tack the branch name onto the package name that I push up. That smells bad, but it guarantees that a branch deploy will always pull its own latest package.

The context here is a shared Jenkins pipeline that performs build, tag, publish to proget, and deploy, with specifics depending on the branch. I’ll be happy to do a deep dive, I’m sure there’s a ton of stuff I’ve done wrong.

I’ve lost the thread here a bit. To get back to the topic, I agree using retention policy is the best way to do what I’m after, with one question: how can I remove all versions of a package once it’s no longer needed, with that defined by the branch being deleted? I know that’s not an option in the retention policies, but what might have a similar effect?

Thanks
max

MaxCascone

I think I can get close enough, without a lot of complexity, by using the retention rules, and setting them fairly tight since it's a dev feed and these packages are meant to be transient.

We don't have a package promotion process right now, although it's on my roadmap. These rules may have to be revisited when i implement that.

Right now I've got it set for:

Delete unused versions not requested in last 30 days.

We are not great at deleting old branches, so this might actually be better than a branch-delete trigger. And if someone comes along and needs an old branch build, they can just rebuild it.

We don't really use the connector feature for our own feeds (or any), so i think this will do it.

I got a little confused at the combination of "keep only last 5 versions" plus the 30-day window. From what i've read in the docs, all conditions must pass for the item to be deleted. How do i set up, "keep only the last 5 versions, but when nothing has been requested for 30 days, delete them all"?

This solution has the benefit of simplicity and native functionality. I don't have to write a hacky, multi-tool process to manage it.

stevedennis

@mcascone sounds like some great progress!

I got a little confused at the combination of "keep only last 5 versions" plus the 30-day window. From what i've read in the docs, all conditions must pass for the item to be deleted. How do i set up, "keep only the last 5 versions, but when nothing has been requested for 30 days, delete them all"?

We could definitely improve the docs on this area, and you're right all conditions must be passed for items to be deleted. When you add the "keep only the last 5 versions" rule, there will be, at a minimum 5 versions of a package.

You could be able to add a second rule, but it operates independently. More like an "OR" than an "UNLESS" I guess. Perhaps you could adjust the time-windows a bit?

Rule 1. "Delete unused versions not requested in last 10 days." AND "Keep only last 5 versions"
Rule 2. "Delete unused versions not requested in last 60 days."

I would look at your release cycles for guidance. For example, we release our products every two weeks, though maybe we'll skip a week every now and then. So, no -ci package will be needed past 1 month. And as you said, you can just rebuild if needed.

MaxCascone

You could be able to add a second rule, but it operates independently. More like an "OR" than an "UNLESS" I guess.

So could you say, each rule is an AND of its own settings, and then all rules are OR'd together. If ANY of them resolve, the package is deleted.

yesno?

stevedennis

@mcascone yep, that's a good way of putting it!