Thanks for clarifying this! I did a test run with a package that has not been downloaded before and it seems you are correct: The total downloads per version (on the "Overview" and "All Versions" tabs) are reset to zero, but the statistics under "Usage & Statistics" seem to be unaffected.

Hi @shilpa-christopher_1809, It looks like this didn't get posted to the Support category and it was missed. Yes, ProGet can be moved to Azure. We actually have a guide on how to move ProGet to Azure. Please let us know if you have any other questions! Thanks, Rich

Hi @marc-ledent_9164, BuildMaster requires SQL Server to run and cannot be replaced with PostgreSQL. But, you can use BuildMaster to manage the change scripts for a PostgreSQL database. You will just need to install the PostgreSQL extension and create a PostgreSQL database connection. You can learn more by reviewing our CI/CD for Databases documentation. Please let us know if you have any other questions! Thanks, Dan

@can-oezkan_5440 just an update, we plan to ship this in the next maintence release in ProGet as PG-2111

Hi @claes-hermansson_6271, Great! Our recommend three-feed workflow (unapproved, approved, internal) is similar, and keeps the third-party packages in the first two feeds. This way, you can scan for vulnerabilities much more easily. As I understand it though, to get full coverage the pgscan tool needs to be installed on every build server, and the pgscan publish... command needs to be implemented in every build? This is correct. Dependency resolution is complex and often nondeterministic, so it can only really happen at build-time. Hopefully you can templatize pretty easily :) Cheers, Steve

@jan-primozic_9264 thanks for posting the update! Please let us know if you can see a place for us to improve documentation :)

Hi, thanks - yep, it appears that plugin is assuming that field is not null. Good find! There aren't any errors from proget either in the output of the plugin upload in the jenkins console, or in the proget error logs, as far as i can tell. Plugin issue: https://issues.jenkins.io/browse/JENKINS-67923 Thanks again for all your great help!

Hi @kichikawa_2913, Good catch! It looks like this is missing from our documentation. I'll work to get it updated this week! Thanks, Dan

The 400 (Bad Request) status code indicates that the server cannot or will not process the request because the received syntax is invalid, nonsensical, or exceeds some limitation on what the server is willing to process. It means that the request itself has somehow incorrect or corrupted and the server couldn't understand it. The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method . Therefore, it prevents the website from being properly displayed. The main thing to understand is that the 400 Bad Request error is a client-side error. The cause of a 400 error can be a wrongly written URL or a URL that contains unrecognizable characters. Another cause of the error might be an invalid or expired cookie. Also, if you try to upload a file that's too large. If the server is programmed with a file size limit, then you might encounter a 400 error.

Hi @p-boeren_9744 , The documentation isn't very clear I had to look this up myself in the code. If you set the allowed property, then a global rule is also created. Therefore, the following should work instead: { "licenseId": "package://@progress/kendo-react-grid/5.0.1/", "title": "package://@progress/kendo-react-grid/5.0.1/", "urls": [ "package://@progress/kendo-react-grid/5.0.1/package/LICENSE.md" ], "allowedFeeds": ["NpmLicenseTest"] } Cheers, Alana

Hi @bryan-ellis_2367 , I'm not an Azure DevOps expert, but last I checked, it's not possible to add NuGet package sources other than it's own ADO Packages product or the public repositories. That may just refer to "upstream sources", but I'm not totally sure. However, if you want to use the ADO Pipeline's built-in NuGet commands to publish packages, I guess you can set up a service connection using this? https://docs.microsoft.com/en-us/azure/devops/pipelines/library/service-endpoints?view=azure-devops&tabs=yaml#nuget-service-connection Not totally sure -- but please let us know what you find :) Cheers, Alana

Hi @moriah-morgan_0490 , Glad to see the environment un-scoping worked! It's definitely possible to get environment-scoping of credentials to work... but it'd probably be best to confirm what you're looking to accomplish. The main purpose of the environment-scoping is to enable limited management access to Otter. For example, users can edit/maintain all configuration except for production servers. Take a look at Multiple Environments per Server to see how the behavior works. I assume that you're running the Inedo Agent? We're still learning the exact privileges ourselves We've seen systems restricted in very unexpected ways (and only in the field of course, never or own environments), and they don't give any logical error messages. But we'd love to help you get this working, so we can document it. Here's what we know so far: local administrators seem to have no problems; this is what most people do, because it's domain credentials they are interested in using and it doesn't matter if they're an admin on that particular server try running the Inedo Agent as the user you wish to impersonate as; this will identify most permissions issues make sure the user target has permissions to the extension cache path and appropriate root paths; see the Agent Configuration File "run as a service" permission seems to be important logging into the server as the impersonated user (at least once) may help for some scripts, so we've heard antivirus or other security tools may block this impersonation as well Let us know what you find :)

Hi @mcascone, We don't have that functionality in ProGet, but it should be pretty easy to do with a pair of Invoke-WebRequest PowerShell commands :) You could probably parse/scrape the HTML and download / upload in bulk as well. Please share the script if you end up doing that, it might be useful for other usecases as well! Cheers, Alana

Hi, Thanks for reporting this. We've now fixed this internally as PG-2105 - it will be included in this week's 6.0.9 release, scheduled for Friday. -Greg

Hi @mail_6495 , Looks like this was a regression with API Key Authentication; the uploader control improperly required an API key. This will be fixed in PG-2104 on this Friday's maintenance key update. Cheers, Alana

Hi, i'm reopening this thread as the public docker connector has been available for a while now, but I can't figure out how to use it. I have the connector set up to point at https://registry.hub.docker.com The setting Do not attempt to search the container registry was automatically enabled. I have a feed public-docker set up to use the connector. The connector shows Active and Healthy, although it shows no known package count (I believe this is expected). Overall, I'm not sure how to use it. The documentation reads as self-conflicting, although I don't know enough about it to say that for sure. That's why I'm asking. From https://docs.inedo.com/docs/proget-docker-connectors: You can also create a connector to an external (non-ProGet) registry such as Docker Hub. This could be useful to whitelist certain base images, or to cache them on your local infrastructure. but then... Many external registries such as Docker Hub do not expose an API for searching and discovery of images, so the ProGet web UI cannot be used to search or browse for images stored in one of these registries via connector. So, i see that I can't search in the UI for images. That's alright, but how can i make sure my docker pull or docker run commands go through the ProGet feed, so the images can be cached, instead of directly out to the Docker Hub? Thanks!

It is pretty easy; I just wanted to know. Thanks for the reply!

Then we have something to look forward to, could be that we by then switched to API Keys, but the decision ain't mine. Thanks for the help and for all the RC that we got to test.

Hi @paul_6112 , The general philosophy that BuildMaster was designed around is this: A "Release" is an intended set of changes to production A "Build" is an attempt at implementing those changes When a "Build" makes it to production (i.e. the final stage in the pipeline), then the changes were applied to production, thus the "Release" has occurred If you want to change production again, then you create a new "Release" This means that, after build of 1.1 is successfully deployed to production (and no rollbacks are needed, etc.), it cannot be released again. You'd need to do 1.2, or so on. However, in practice users want to deploy 1.1 build 1234 to production, and then 1.1 build 5678 to production. So with this, we have a few options: Create the releases 1.1.1234 and 1.1.5678, and then have build 1 (sounds like you're doing this) Create Release 1.1.0 Build 1234, Release 1.1.1 Build 5678, and use a Release Name of 1.1 (this overrides the display in nearly all places) Edit the pipeline, and uncheck "Mark the release and build as deployed once it reaches the final stage."; this will give you more control over changing release status Don't use releases at all (set Release Usage to None on advanced settings), and have the build number be 1.1.1234, 1.1.5678 Definitely open to some other ideas as well. A few users have had to "workaround" this design philsophy, and we'd rather just support it!

Hi, Thanks for the bug report! We've logged and fixed these as PG-2098 and PG-2099. Note that due to limitations in how that dependency table is built, it's nontrivial to have it take you to the latest package that satisfies the given range if it has an exclusive upper bound - but we have changed it to prefer linking to the upper version number if one is present. -Greg