[ProGet] Feature Request/Inquiry: Feed settings when creating using PGUtil/API

Nils Nilsson

Hello!

I'm working on setting up an automated configuration of feeds for new Products/Projects in my organization.

When reading the documenation for Create Feed I noticed that the API which expects a ProGetFeed.cs object supposedly would allow you to set many extended options for a feed, such as Connectors, or PackageStatisticsEnabled. ProGetFeed.cs
As far as I've been able to tell, none of these options are available for setting when creating through PGUtil which basically only allows you to specify Name and Type, and soon also Group as we discussed previously here.

My first question is if this disparity in options between API / PGUtil is intentional and that advanced usecases should primarily aim to use the API for interfacing?
Or if there are options available in PGUtil that maybe remain undocumented in helpstrings/web docs?

My follow up question is if you intend to/would consider extending the options available in PGUtil?
If you do not want to laden PGUtil with a ton of options, would it be possible to implement a "New Feed Template" so that the default value of at least Feed Features Downloads, Deployments, Usage, Software Component Analysis could be changed to Enabled instead of Disabled?

Best Regards,
Nils Nilsson

dean-houston

Hi @Nils-Nilsson,

To create feeds with different settings, you'll can use multiple pgutil commands like this:

$ pgutil feeds create --name=myNugetFeed --type=NuGet
$ pgutil feeds properties set --feed=myNugetFeed --property=dropPath --value=c:\bulk-import
$ pgutil feeds retention create --feed=myNugetFeed --deleteCached=true --keepVersionsCount=5 --keepUsedWithinDays= --rule=1

This was intentional and the "list/set" approach is by design.

As for why it differs from the API so much.... to be totally honest, we all hate the Feed Management API. Not just the endpoints themselves, but the code that implements it.

We planned to rewrite it, and perhaps the "list/set properties" was a part of that idea... but we eventually realized the only thing worse than the current Feed Management API would be having to maintain it along with a whole new version. So, we're stuck with it.

Anyway, we'd be open to expanding the options in pgutil, but it's not on our roadmap of priorities right now. We would very much welcome a pull request if there are properties you'd like to add:
https://github.com/Inedo/pgutil/tree/thousand/pgutil/Feeds/Properties

-- Dean

Nils Nilsson

Hi @dean-houston

Thank you for the detailed response.

I'll dive into the properties set and retention create commands to see if the current implementations already cover our automation usecase.

Fair point about the API, then I'll continue to default to using PGUtil so that you at least have one less user depending on the API in case you want to supercede/deprecate it in the future :)

Best Regards
Nils Nilsson