Hi @daniel.mccoy_4395 , Actually, developer experience is a big reason we don't recommend using Download Blocking. A 400 error provides no real context. Developers can see something is wrong, but not how serious it is or what to do next. First and foremost, an unlisted package should not be noncompliant. An author may decide to unlist their package for any number of reasons, including simply not wanting too many versions to show up in a list. This would mean that, all of a sudden, a build deployed to production can suddenly be considered as noncompliant just because an open source author arbitrarily flipped a switch on NuGet.org. That's not to say you should ignore the unlisted flag, but you should definitely not put it at the same categorization as a GPL3 license or severe vulnerability. "Compliant with Warning" could be a more appropriate status here, but keep in mind that developers swill naturally upgrade dependencies as they do platform updates, so it may not even be worth worrying about. Especially if it leads to constant warnings -- in that case, warnings become meaningless. Noncompliant packages should be rare for the same reason. If noncompliant can be determined by an OSS author's whims, then it really caries no meaning and no one (especially your developers) will understand/appreciate what it means. As for the workflow to use, we recommend running pgutil builds scan when that pull request is run. That will not only put the build in ProGet, but it will produce a text report with warnings or noncompliant packages. A ProGet login is not required. If there are Noncomplaint packages or warnings, the developer can then comment on the PR why it's nothing to worry about. If it's always the same package/issue ("we cannot upgrade from this 5-year old library and replacing it would be a substantial effort"), then you can formalize that as an exemption. The advantage to this workflow is that, if a deployed build later becomes noncomplaint (typically due to a vulnerability), then you can decide how and when to address it. The wrong time to address noncomplaint packages is "the next time a developer happens to open this project". Overall, what you want to avoid is having developers load a project for what should be a trivial change and then have to upgrade dependencies because it produces pointless warnings/errors. That will just create a "constant upgrade" mentality. That leads to constant regressions and constant headaches for testers or end-users, who have to deal with strange and unexpected errors from library upgrades. Hope that helps, Alana

Hi @rcpa0, It's hard to say, but maybe it has something to do with how the package file / archive was created. Can you share the file or a reproduction case? Thanks, Alana

Hi @brandon_owensby_2976 , Thanks for clarifying; it got a little distracting with the desire to have PR cleanups and specialized variables! We also see a lot of anti-patterns in Git repositories, such as using PRs for workflows, because that's how open source projects tend to work. Anyway, it sounds like you figured it the first part, which is to set the monitor to just create a build with a specific pipeline (e.g. "Feature Branch" pipeline). The next step, just use a retention policy that targets builds that have completed the pipeline. For example: 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

Hi @atripp That's great, thank you :)

Hi @Nils-Nilsson, Sorry on the slow response; we finally got the chance now to prioritize some roadmap items. In any case, this will be implemented as PG-3337 in an upcoming maintenance release (targeting July 24). Thanks, Alana

Hi @xabur , Thanks for sharing the additional information! I've been meaning to research this more in depth, but just ran out of time. I can't quite seem to figure out what Open VSX is exactly. So far as I can tell, it's like an alternative the Visual Studio Gallery. Meaning, you plug in https://open-vsx.org/ in VS Code, and then all the requests go through their service instead of the official gallery? If that's the case, what's the use case? They appear to have all the same extensions, so this just feels like one of those "GooglePlay store alternatives" on Android... except there's no account/registration/etc required with the Visual Studio Gallery. Right? Open VSX clearly seems to be popular, I just don't understand why. In any case, if a well-supported project "reverse engineered" the official gallery and then made an alternative, that kinda paves the path for us. We don't want to be the first or only game in town, when it comes to supporting feed types. Thanks, Alex

Hi @pmsensi , Oh sorry I didn't realize or notice it when reviewing the reply. We decided not to include it after all, mostly because we couldn't realistically model/generalize the data across ecosystems when it comes to things like how NPM handles dev-level dependencies, how PyPI handles environment dependencies, etc. The UI display garners a decent number of "complaints" because it doesn't represent it the same way as say, npmjs.org for example. That said, the manifest file (i.e. .nuspec) is cached in the database, but there's no "ProGet" API to retrieve that. You'd have to use the NuGet-specific API for that, or just download the package file and then extract the .nuspec file. Thanks, Alana

@atripp said: ust as an FYI, I submitted two pull requests for this: Thank you very much, Alana!

Hi @paul.moors_5682 , Without more details it's hard to say; this may be normal/expected depending on the feed type. The numbers displayed in the UI show what information is in the database, not what's on disk. So it's possible to have files on disk that aren't in the database, and vice versa. The Feed Integrity scan (part of ProGet 2025+) will help identify database entries without files. Then, you can run a "feed reindex" you can chose to delete database entries for missing files. Hope that helps, Alana

@manuel.riezebosch_8638 the purl argument was never actually read, so you could have really put anything in there :) It was just one of those docs error; many other api endpoints will use a purl argument And you're right... all the other package types have metadata inside the package, so that's what's read. Some require a file name, but Debian is an outlier in that it requires a distribution argument as well.

Hi @stevedennis, Thank you very much for your answer. From what I've read elsewhere, that's exactly what I thought. By the way, and besides that, ProGet is a really great tool. Good job ! Regards, Olivier

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

Hi @jeremy-oaks_9309 , Just wanted to respond to this real quick: I have ~80k packages (~600GB) -- so we're opting for the stand-alone database for performance purposes Based on this information we still recommend using the embedded database; it's almost always going to be more performant as well as simpler to maintain. 80k is not that many packages by any stretch. While @pg_user_8607 is correct in that it's a bit easier to monitor database performance, investigate issues like bad queries, and do DBA maintenance tasks - that's all technically "our job". From a user perspective, the only required "database maintenance" should be backing up the files. We certainly don't mind the help (and users like @pg_user_8607 have helped us out a lot!!), and it may be quicker if you "know what you're doing" to get to a root issue, since we're not all exactly experts at all these layers. But I just wanted to make sure you were aware of the pros-and-cons. Thanks, Steve

Hi @brandon_owensby_2976, I wasn't able to reproduce this issue, but looking over the code, I can see a few scenarios in which "not configured to allow access to encrypted values" will trigger, even if that's not accurate. It's not trivial to rewrite that to provide a more accurate error message or credential resolution, so we'll add this to our BuildMAter 2027t roadmap and review it more closely then. In the meantime, I would just use a variable and duplicate the information. Thanks, Steve

Glad I could help! We'll get that documentation updated as well.

Hi @brandon_owensby_2976 , You can configure release settings on an application-by-application basis under the Settings tab. In this case, you'd set Release Usage to be Optional or Disabled. If Release Usage is set to Required, users must select a release when creating a new build; this was the deefault in older versions of BuildMaster. https://docs.inedo.com/docs/buildmaster/modeling-your-applications/buildmaster-releases Cheers, Steve

Hi @fabrice-mejean , Thanks so much for the detailed information and offer to connect further! Very interested in that and I will definitely take you up on that :) Please give me a little time for that; I've got some travel coming up and then a bunch of other things... so I'd like to connect when I can really focus on some of these future things. . Cheers, Alex

@Nils-Nilsson excellent, let us know as you have other feedback too! This is definitely an area we intend to keep improving in throughout ProGet 2026+

Hi @carl-westman_8110 , Thanks for sharing that. This isn't a symptom of "server overload" that we've seen before. The error you shared is occurring on Feeds_GetFeeds, which is definitely not an intensive query, and I would not expect that to be timing out at all. It's just SELECT * FROM [Feeds]. However, that's a similar symptom to the "AzureSQL resource throttling" that we've seen on other users: another query is being throttled (for example, something that joins on [Feeds]), and that is causing a cascading impact on other queries. We don't have enough information to say that's the case here. But, an easy way to test would be to up your DTUs substantially. Otherwise, the next troubleshooting step is to try to identify the cause of the timeouts, which involves looking at HTTP Access logs and jobs occurring around the same time under Admin > Scheduled Jobs. Thanks, Steve

Hi @jeff-miles_5073 , You can get information about images and tags using the Docker API; we do not provide documentation on how to use that (see our caveat on Feed Endpoints). And unfortunately the Docker API is a bit awkward, but with enough ChatGPT you should be able to figure it out :) You could also query the database directly, perhaps building some kind of data export tool so that you can sync it with your dashboard. Hope that helps, Alana