ProGet: Strategies for (more) flexible feed naming

[gbeckett]

Hi all,

I'm currently setting up a new ProGet instance, migrating from a relative large instance with a few "catch all" feeds, to a new install with a more granular set of feeds. Ideally, I'd like to implement consistent set of URL patterns, including possible forms of 'namespacing' for multiple tenants, and clear separation between repository types (including in paths). We use CI/CD heavily to validate e.g., registry usage; so being able to create some consistent patterns would be great.

Based on the current options and documentation, I understand that the following patterns apply (by default);

• single "URL segment" feed name, no urlencodable characters (i.e., no / allowed)
• always prefixed with a feed type, though depends on the feed type, e.g.;
  • nuget for NuGet, PowerShell, Chocolatey
  • helm, npm, etc. for their respective package managers
  • Docker has no path prefix
• alternate names can be defined, but have the same restrictions

This can lead to somewhat restrictive and sometimes confusing feed URLs (e.g., the debian prefix being used for general apt-compatible systems, the Docker feeds having no prefix at all).

I'm therefore wondering if there are alternative strategies to allow more flexible feed naming? Possibly via internal configuration or otherwise?

One option I'm considering is layer a proxy in front of ProGet, to provide the URL rewriting to map to ProGet-compatible names. e.g.,;

• proget.org.com/ps/tenant-a to proget.org.com/nuget/ps-tenant-a
  or
• proget.org.com/docker/tenant-a to proget.org.com/docker-tenant-a

I would love to head your thoughts.

Best,
Cyril

[stevedennis]

Hi @gbeckett ,

There are Feed Names (which you can configure) and API endpoints (which you cannot configure).

Our general guidance on feed names is internal-nuget or public-nuget, but we've seen cases where a lot of feeds are needed. I suppose tenant namespace like tenant1-nuget might work too. But like naming of everything else, you'll figure it out as you go.

While you can't change API endpoints, you could use the alternative /endpoints url if you really wanted. So instead of /nuget/public-nuget it would be /endpoints/public-nuget. Honestly I wouldn't bother... it's just a URL that no one really sees, and that's actually going to make it more of a pain to support. That's why we don't expose this.

Some ecosystems (like Docker) only support one registry per domain/port, which is why Docker feeds have no prefix. We work-around this by using namespaces.

One option I'm considering is layer a proxy in front of ProGet, to provide the URL rewriting to map to ProGet-compatible names.

Please don't do this :) We do not recommend nor do we support URL rewriting like this. People have figured out how to do it, but it causes lot of headaches and it will be painful to debug. Which is why we don't support it. Again... it's just a URL that no one really sees after you enter it.

Hope that helps!

Thanks,
Steve

[gbeckett]

Thanks for the tips. That Docker constraint is particularly good to know, I hadn't realized!

We do have a rather large amount of feeds to manage, including a (growing) set of feeds we use as local mirrors. I'll see if we can find an alternative solution that works for us...