@zs-dahe said in Retention Activation via API?:

with the Feeds API it is possible to add retention rules for feeds (https://docs.inedo.com/docs/proget/administration/retention-rules). However, I don't see a possibility to actually activate the retention for a specific feed via the API. Am I missing something or is the retention intended to be activated only via the web UI?
Our usecase is that we would like to activate a specific set of rules to many feeds at once. For this, we must also ensure that the retention is actually activated and an API endpoint would be convenient to enforce this.

Hi Alana,

thanks for the quick reply. I opened a feature reqeust ticket for this :)

Best regards
Daniel

Hello,

with the Feeds API it is possible to add retention rules for feeds (https://docs.inedo.com/docs/proget/administration/retention-rules). However, I don't see a possibility to actually activate the retention for a specific feed via the API. Am I missing something or is the retention intended to be activated only via the web UI?

Our usecase is that we would like to activate a specific set of rules to many feeds at once. For this, we must also ensure that the retention is actually activated and an API endpoint would be convenient to enforce this.

Best regards
Daniel

Hi,

we are trying to incorporate the package promotion feature into our workflow and would like to use the API endpoint for that. Our scenario imposes the following requirements:

• Both the source and target feed should be restricted to specific API-Keys only (i.e., we cannot allow anonymous access).
• Furthermore, both feeds are in a feed group which also contains various other feeds. We use this feed group for other permissions, and thus cannot move the two feeds to another group.
• Since the package promotion should be triggered in a CI environment, we cannot use impersonated api-keys.

It seems that it is only possible to specify a single API-key for the package promotion endpoint. Thus, we cannot use a feed-specific API-key for the promotion. We therefore need to create a key for the whole feed group with both read and promotion permissions. Unfortunately, this key now has too much permission than actually needed, because it can also access the other feeds in the group.

Is there anything I'm missing or something that we could do differently? We really would like to adhere to the principle of least privilege for those feeds, i.e. not giving the API-Key far more permissions than it needs. If that's not possible currently, are there any plans to a) either allow a feed to be in multiple groups, b) give the promotion endpoint the possibility to have two different API-keys, or c) define the permissions for an api-key more fine-grained?

Thank you for this clarification. We would like to use the asset directory to store the most recent version of a file that is periodically generated by an automated task (once a week). The old versions of the file are only needed as backup in case that something went wrong during the automated build. Thus, we only need the last few versions of the file and only need to access them in rare cases. The retention feature would be useful because with versioning enabled the individual versions will quickly take up considerable space.

Would it be worth trying for us to automate this retention rule through the API?

Unlike for the package feed retention rules, there doesn't seem to be a possibility to keep the last N versions of a file in an asset directory (with versioning enabled). In the documentation, it says that with the retention rules it should be possible to "delete old versions of assets". However, I don't see a way to achieve this in the UI, since it only can filter versions based on the number of downloads or the download dates. In our case, it isn't guaranteed that a new version of a file is downloaded, but we still would like to keep it in the asset directory.

Am I missing something here? Is there a way to enable similar retention rules for the asset directories as there are for the package feeds? Specifically, we either would like to keep the last N versions of a file, or alternatively have the option to remove all files that are older than X days.