@atripp @joshuagilman_1054

TIL that PowerShell can use internal CLR generic reference type names like that! But really, please don't do that...

• [System.Nullable``1[[System.Int32]]]
• [Nullable[int]]

... much easier to read

Hi @d-kimmich_0782 ,

This behavior is by design; the "publish date" in ProGet 2025 and earlier is whenever a package is added to a feed. This means that, even if a package was published to NuGet.org 3 years ago, the "publish date" will be whenever it was first cached.

However, in ProGet 2025.14 and later, you can change this behavior under "Admin > Advanced Settings > Use Connector Publish Date". This will be the default behavior in ProGet 2026.

This is being done for a similar set of rules you should investigate, which we call Recently Published & Aged Rules :
https://docs.inedo.com/docs/proget/sca/policies#recently-published-aged-rules-proget-2026-preview

-- Dean

Hi @Nils-Nilsson ,

Thanks for the bug report; it seems to issue is on the "view" page, and it's mistakenly editing the wrong data.

PG-3258 will fix this in the next maintenance release (April 17), but a prerelease is now available (inedo/proget:25.0.26-ci.6) if you'd like to try it.

-- Dean

You can ignore this error; for whatever reason, the NuGet client unexpectedly terminated the connection, and the result was that ProGEt stopped writing bytes. Not really anything to worry about.

The diagnostic center isn't for proactive-monitoring, more for diagnostic purposes. So ulnless users are reporting a problem, you don't need to check it.

Hi @andreas-unverdorben_1551 ,

npmjs.org primarily serves static content and runs on massive server farms running in Microsoft's datacenters.

Your ProGet server is much less powerful and does not serve static content. Not only is every request is dynamic (authentication, authorization, vulnerability checking, license checking, etc), but most requests (such as "what is the latest version of package X") need to be forwarded to npmjs.org and aggregated with local data.

So, a much less powerful server doing a lot more processing is going to be a little slower ;)

Running ProGet in a server cluster will certainly help.

Cheers,
Dean

Hi @kichikawa_2913,

We see multiple connectors pretty often, and it rarely presents a problem.

The main downside comes in the overhead of aggregation; for some queries like "list all package versions", each connector will need to be queried and have the results aggregated. So it could cause performance issues for for very high-traffic feeds - at least that's what we see on the support side of things.

However, if you plan on using a package-approval workflow, then it won't be a problem, as your approved-npm feed wouldn't have any connectors.

Hope that gives some insight,

Dean

@joel-shuman_8427 thanks for the heads up!

I just updated it
https://github.com/Inedo/inedo-docs/blob/master/CONTRIBUTING.md

Hi @jimbobmcgee ,

Thanks for all the details; we plan to review/investigate this via OT-518 in an upcoming maintenance release, likely in the next few two-week cycles.

-- Dean

Hi mwatt_5816,

BuildMaster does support "release-less" builds, though you may need to enable it under the application's Settings > Configure Build & Release Features > Set Release Usage to optional. That will allow you to create a build that's not associated with a release.

It's also possible to do "ad-hoc" builds (i.e. builds with no pipeline), but we don't make it easy to do in the UI because it's almost always a mistake (once you already have pipelines configured). So in your case, I think you should create a secondary pipeline for this purpose.

-- Dean

Hi @mmaharjan_0067 ,

It sounds like you're on the right track with researching this; your reverse proxy is definitely "breaking things" somehow.

Based on what you wrote, it sounds like your reverse proxy is terminating the request because there's no output from the server after a while. The "no output" is expected, since assembling the upload takes quite some time, and that's likely where the "operation cancelled" would be coming from.

I would look there and see if you can adjust timeouts. As for pgutil, here's the code used to perform the multi-part upload:
https://github.com/Inedo/pgutil/blob/thousand/Inedo.ProGet/AssetDirectories/AssetDirectoryClient.cs#L197

-- Dean

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