@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 @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