Hi @gisleso ,

What you're describing has come up lately, though with a slightly different angle.

I'm going to quote a variant of this, from a recent support ticket.

We are trying to establish a policy where packages newer than 30 days are blocked on the package server level.

Unfortunately, we are unable to use the feature they way it currently works, unless we are missing something.

As soon as we block packages in any capacity, we are unable to do even the most rudimentary pip install or uv sync operations, as transitive dependencies cannot be downloaded (same for npm actually, but that is not an important package manager for us).

I assume it has to do with how these package managers generally work:

1. They construct a dependency graph from the available versions, taking various rules like locks and version ranges into account.
2. After they built the graph, they will try and download the versions they have selected, which fails in most cases on ProGet, because the versions that are advertised by the index may not be available.

We're a bit surprised by this behavior, because it seems like versions that cannot possibly be downloaded should not be present in the index.

We think ProGet should not advertise versions in the index that it blocks.

There are options with some package managers to take a cut-off date into account when calculating the dependency graph, but defining that in code on every single piece of code we have throughout the org defeats the purpose of having a central repository that should be able to do that.

Are we missing something? Can we hide the versions that are noncompliant from the PyPI package index, or could that be enabled? This is a rather critical feature for us.

And for more context, here's some of our response:

This is a somewhat frustrating technical limitation; it comes down to the fact that we often can't know if a package is Noncompliant until we have the full metadata and even the package file.

The API examples you shared illustrate this exact problem; consider what happens when you make that same request to PyPi.org (i.e. curl https://pypi.org/simple/certifi/). It's a long list of versions of that package, but there's no additional metadata.

That means ProGet wouldn't be able to filter that list without querying the metadata of each version -- and that's just not technically feasible to do. Some clients can actually be configured to do that (like pnpm), but they can take a more context-sensitive approach. For example, they'll start by downloading B-1.2; then, if it's too new, it downloads B-1.1, and so on. Obviously a server can't know what the client wants with the data.

Anyway, this is a known issue it's something we're researching. We call it "Metadata Suppression", but there are a few other major Developer Experience issues as well. The biggest one is that there's simply just no indication that these packages are being hidden by ProGet. So a Package Restore through ProGet will behave drastically different to the public repository, and eventually that will just lead to developers not trusting or using ProGet due to erratic behavior. That's a not a situation either of us (i.e. us as the software vendor, you as the platform ops team) want.

Our general guidance is to simply not block downloads at all actually; we consider that an anti-pattern. It adds no protection whatsoever while substantially increasing risk by lowering the organizational security posture.

Quite simply, developers will work-around what they consider "braindead policies" to get their job done. Upper management will not intervene nor punish them for delivering on time, etc. Ultimately the only consequence will be that no one will take your team (i.e. those enforcing policies) seriously. We've seen this happen time and time again; it's a version of "shadow IT".

Instead, you should use pgutil builds scan and then consider these on a case-by-case basis if they are issues: https://guides.inedo.com/vulnerability-management/containment/

To summarize, the "version dance" isn't realistic to do at the server level, for the reasons articulated above. Even if it were technically feasible, It would create a poor developer experience.

THAT SAID -- we are considering an experimental approach. ProGet could "auto-yank" noncompliant packages. I'm envisioning something with three options for Noncomplaint packages:

• Block File Download (not recommended)
• Emit Deprecated in the API (experimental)
• Allow Downloads (default)

Will clients like pip and uv avoid deprecated, newer packages? We aren't users of these tools (or python at all), and we'd love if you could help us "test" this by manually deprecating some newer versions, and see how it handles dependency resoltuion.

-- Dean

Hi @Nils-Nilsson ,

That message appears to be coming from SetCommand.cs#L91... is it possible you're not on the latest pgutil (i.e. 2.4.2)?

That would be my guess...

-- Dean

Hi @dan.brown_0128 ,

Here's our current position on MCP Registries:

From a quick read of the documentation, it looks like an "MCP Registry" is mostly just a JSON document that lists "MCP Servers". There don't seem to be "Packages" (i.e. an archive file with a manifest file) nor a "Central Repository" (i.e. a canonical location where OSS Models are stored), which means it's not a great fit for ProGet.

Here's the current discussion on the topic: Request to support MCP registry; I'd encourage you to add your thoughts to that!

-- Dean

Hi @jimbobmcgee ,

Long story short, "we're not entirely sure anymore."

You've picked up on the original intent: these are intended to provide UI-based inputs around script parameters. And they do "mostly" show up in the use case you identify (i.e. when creating a Job Template for the first time)... but they are overall a glitchy feature.

They were also intended to allow for Param()-like support to other scripting languages, so you'd simply need to add that header to the script and it would just "work" in OtterScript and job templates.

From an engineering standpoint, we had planned to improve all of these after Otter 2022 (when they were first released), but our R&D priorities suddenly shifted. So we haven't had time to revisit them (or other Otter features we wanted to do), and they're basically in that same glitchy state

Personally I thought they were a pretty neat idea, and it's just unfortunate we weren't able to take them further. But, so it goes with development priorities...

-- Dean

Hi @amy.j ,

Looks like the code was actually merged in and shipped, but that status wasn't reflected on the YouTrack issue, so the note didn't get added to the release.

Anyway I've modified the status and manually updated the release notes now.

-- Dean

Thanks @brandon_owensby_2976 , we appreciate the additional context and it makes a lot of sense.

Just to give you more context on our end on why we aren't changing the software here very much, we aren't focusing very much on "download-try-buy" channel for BuildMaster (i.e. the way you're evaluating the product). Instead, it's sold as the technology to help implement Lean Platforms transformation, which necessities improving the development workflows.

One thing we'll be releasing as part of BuildMaster 2026 (coming fairly soon) are features to better handle parallel release tracks across multiple applications, including this new calendars feature:

@brandon_owensby_2976 fantastic!!

Thanks much; I'll let our technical writing team review/accept it, They should within a day or so

-- Dean

Hi @brandon_owensby_2976 ,

We can certainly update the documentation; what would you suggest to change?

https://github.com/inedo/inedo-docs/blob/master/Content/BuildMaster/administration/retention-policies.md

Feel free to submit a pull request as well :)

As for how we handle feature requests, it either gets "added to our roadmap" or not. If not, then it just stays "in the ether" until it comes up again.

When it comes time to plan for a release (e.g. BuildMaster 2027), we choose from items from that roadmap (it's an internal checklist) or shift them to next year.

After a few shifts, we remove it from the list and goes back "to the ether". Redoing Retention Policies in BuildMaster were on the roadmap for an extremely long time, but there are just so many areas of improvement that kept coming up instead. And that's why it's not on our roadmap now.

The forums are a great way for users to vote or share ideas, so this someone can always reply to this post in the future.

-- Dean

@brandon_owensby_2976 I definitely do not recommend it, but if you are intent on creating something that automatically promotes feature branch builds to a "rejected" stage, you could code a custom PromotionRequirements.

You'd be much better doing something on the GitHub side that promotes a build using the API, however.

Hi @brandon_owensby_2976 ,

While it's technically possible to create a custom repository monitor (see the Subversion one), I'm not sure if I'd recommend it for this use case.

Did you see our guidance here on build clean-up?

https://docs.inedo.com/docs/buildmaster/builds-continuous-integration/buildmaster-ci-git-workflows/buildmaster-git-feature-branches#cleaning-up-feature-branch-builds-with-retention-rules

In a feature branch pipeline, a build should still be promoted to a final stage ("merged" or something), and once that happens it's status can be set to Rejected. So, instead of worrying about whether the PR is merged/deleted, just delete rejected builds after X days.

-- Dean

Hi @cyril ,

Thanks for checking; that would be fine. Note you'll have to enter a license key in your scripts (free is fine), as ProGet will not automatically create a license key.

Aside from various features missing from Free edition, one restriction is that ProGet Free can't connect to other instances of ProGet. The software will generally enforce this as well.

-- Dean

Hi @daniel.pardo_5658,

This behavior is somewhat expected.

I'm not really a Debian expert or anything... but when it comes to a Debian repository index, all is actually the name of a component.

When we look the index files, we can see:

• ubuntu-jammy has all components
• ubuntu-jammy-updates has no all components
• ubuntu-jammy-security has no all components
• ubuntu-noble has all components
• ubuntu-noble-security has all components
• ubuntu-noble-updates has all components

I would have thought that any means "any component", but apparently it doesn't. So I guess you have to specify that list if you want it to work.

-- Dean

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

Hi @Nils-Nilsson ,

Thanks for the feature request; this is not currently on our roadmap.

As you might imagine, it would be a substantial undertaking to develop commands/endpoints for policy management and maintain those through new versions. Given how these will hardly change on an instance of ProGet (most users will have a handful of policies at most), we don't feel the costs bring enough benefit to users.

It's also worth noting -- SCA/Policies are still relatively new in ProGet (and the industry as a whole), so there are a lot of opportunities to improve them. We'd rather invest in that then making them API-editable (which, would make the more complex to change later as well).

Note that it's possible to do through the Policies_* endpoints and stored procedures should you really need to.

-- Dean

Hi @brandon_owensby_2976

I'm afraid we have no plans to touch the (current) retention policies code. It's very sensitive -- and it has quite a few quirks -- but it does work fine once you know how to use it.

At some point, we would like to just rebuild the feature from the ground-up and introduce it as a side-by-side feature. But that's quite an effort and it's not our roadmap at this time I'm afraid.

--Dean

Hi @brad.zinser ,

This is somewhat expected, although the error could be improved.

You're sending a Content-Type: application/json or similar header, which will attempt to read the content body -- but since it's a GET request, there's no body. And at some point, that error occurs.

-- Dean

Hi @brad.zinser ,

I'm having a bit of a hard time reproducing this or figuring out how this might be possible.

What kind of CI do you have set-up? Did you configure anything via the API? If so, would you be able to share the XML used for the underlying Secure Resource (it's in the SecureResources table if you're poking around in the Database)?

You can also go to Admin > Secure Resources to get a more "raw" view of this.

As an FYI, here's the code where it's failing:

However, that property (project.LastSync) is set in exactly one place (project.LastSync = DateTime.UtcNow;), so it doesn't make a lot of sense to me.

Let us know what you find!

-- Dean

Hi @denis.krienbuehl_4885 ,

The files posted on that page do not appear to be Debian packages; they're just .tgz archives containing what appears to just be a single executable file (vdev). Those won't work with ProGet (or any other Debian repository), and would need to be packaged as a .deb archive.

-- Dean

Hi @caterina ,

Glad this is working now! I have no idea what it could have been.... maybe there was some kind of platform/library regression.

We didn't make any WIA/AD/LDAP changes -- just went from .NET8 to .NET10. This stuff is a bit fragile, as you're noticing

Anyway, all good for now! THanks for letting us know

-- Dean