How do project, release and package relate?

Legacy Uncategorised
1

My question relates to ticket 5804.
So, I have an issue with retention policy, some packages are not removed because of #{…} references:

Package.Name.1.1.0.69 was published on 10.11.2015 5:52:53 +00:00. It will be kept. Reason: the package used by a project that uses #{…} references in the package ID field, and the project has deployed a package with this name before.

So, I have to delete it using Rest-API.
The task is to delete packages, which are:

  1. Older than X days
  2. In Y project-group
  3. not included in any release (so do The in-built NuGet repository retention policy)

The problem is that I cannot figure, how do project relates to package and release to package.

I have found only one way:

   /api/projects
     ->
       /api/projects/PROJECT-ID
         ->
           RESPONSE.Links[Releases] = /api/projects/PROJECT-ID/releases
             ->
               Get package name from RESPONSE.Items[id].SelectedPackages[StepName].split(' ')[1]
               Get package version from RESPONSE.Items[id].Version
                 ->
                   api/packages?filter=PACKAGE-NAME
                     ->
                       AllVersions: RESPONSE.Items[id].Links.AllVersions => get all packages
                       ->
                          Exclude version, which was found in release

But it seems to be too tricky. Is there a better way?

2

Hi Titusjaka,

Thanks for getting in touch! I’m afraid I don’t have great news for you - as soon as you use #{...} for your PackageId there is no exact way to calculate/predict which Packages will still be required. Hence why we cannot perform the Retention Policies for this package on your behalf. The reason for this is that we do not know what the #{...} expression will resolve to until we are starting a Deployment. For example, you might have scoped your PackageId variable to an Environment, which isn’t known until we start the Deployment to an Environment.

Risking a stupid question: Is there any way you can use a static PackageId? This would solve all of your problems with Package Retention.

Otherwise the best advice I can offer you is to make a decision about how much risk you are willing to take regarding which packages to retain, and which to delete. Some customers just blindly delete packages older than a certain date, regardless of usage, others will do something like you’re suggesting and delete all packages that have already been deployed.

I’m sorry this wasn’t the news you were hoping for.
Mike

3

Thank you for the answer!
I’m afraid I cannot use static PackageId, because it is used in Step Template. Otherwise I need to create and change every step by hand instead of changing only one template.
So, I hoped there is any way to find connection between project and package without doing all this magic like variables, deployments and so on.

4

Hi!

Thanks for the extra information. I can see the value in the approach you’re taking, but I’m sorry I don’t have better news.

When you end up finding a retention policy that works I’d be happy to help you validate it.

Hope that helps!
Mike