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

Hi @caterina ,

Based on the output of /debug/integrated-auth, it looks like a token is no longer being passed from the operating system. That would explain why the user is not being found in the directory.

Are you using any kind of reverse proxy in front of ProGet? Such as IIS or something?

-- Dean

Hi @caterina ,

This error means that the token being passed from Windows (e.g. DOMAIN\USER) cannot be found in the active directory. I would check /debug/integrated-auth, which will give some more information about how that's parsed.

There are no changes we made that would cause this to happen, so it's possible it's unrelated (I would try a rollback to make sure). Otherwise, it's a consequence of some library/dependency change in the active directory libraries we use.

Unfortunately, regressions in Microsoft's libraries can be "par for the course" with Windows Integrated Authentication, which is why we recommend moving away from it.

That's not to say it won't work, but the best way to handle this is to disable WIA and set this up from scratch again.

-- Dean

Hi @Ashley,

It wouldn't make sense to try removing "vulnerable packages" from storage -- in fact, even download blocking doesn't make sense in most cases, as it tends to lower the organization's security posture and leads to other problems.

Even the package with the "world's most severe vulnerability" (i.e. the infamous log4shell) is harmless unless it's incorporated in an application in a certain way and the application is exposed in a certain manner that would allow a malicious actor to exploit it. Trying to block access or remove these harmless library files from the network will substantially lower the organization's security posture, for a number of reasons.

I'd encourage you to check out our best practices guide: Vulnerability Management Done Right with ProGet. In particular:

• Preparing for a Category 5 Vulnerability to learn how to handle the "next" severe vulnerability
• Blocking & Containing Vulnerable Packages for general best practices in addressing them in pipelines

I think the Preparing for a Category 5 article will help you create that template process for what to do when that high vulnerability package is is identified.

Hope that helps

-- Dean