@mcascone I don't think it's new, but it's just used to specify the dependencies field in the manifest file; I'm thinking, perhaps, it might be similar/identical to the consumes field you added? https://docs.inedo.com/docs/upack-universal-packages-manifest The only thing Inedo tools use it for today is just displaying information in ProGet, on the dependencies tab. That may / may not be helpful.

Hi @stevedennis, having a PackageLicense table would be great for two reasons: a) It would give as the ability to do some reporting on used licenses. b) There are lots of packages that use embedded license files. ProGet already has a feature where we can manually assign the corresponding license to a specific version of a package, but as far as I can tell, this is done by generating a pseudo URL for each package and assigning that URL to the corresponding license. While this does work fine as long as it is done only for a small number of packages, I'm not so sure how it affect usability (and maybe performance) when this is done on a larger scale. Having a separate table that connects packages (or package versions) to specific licenses might be a cleaner way to store and process that information. I'd have to check whether we could give you a dump of our database, but we are only just starting to use ProGet, so there isn't really too much data there yet. The fact that we are new to this is actually the reason we are so interested in reports about licenses and vulnerabilities: We are setting up workflows, etc. and at some point we want to completely block downloads of vulnerable packages or packages that use restrictive/unknown licenses, but before we activate hard filtering rules we want to get an overview on how this would affect products currently in development (so we can adapt our rules or define exceptions). At the moment we are generating data by integrating pgscan to our build pipelines and gathering download statistics for packages (and hope that we will be able to analyze that data in a useful way), so feel free to reach out in a month or so. Maybe we will have enough meaningful data to be of use for you guys by then. Cheers, Sebastian

Hi @atripp , after yours testing I found mistake in URL - my URL was without /package/. When I use proper URL to request, package was succesfully deleted. Thank you for quick support and sorry about my novice mistake ;)

Hi @mcascone, Thanks for following up and letting us know this worked! Thanks, Rich

Hi @kichikawa_2913, Could you please open another topic for the Selenium.WebDriver.ChromeDriver issue? I think that is unrelated to the authentication issue. Thanks, Rich

Hi @Russell-Kahler_4399 , It looks like there was an error running the upgrade scripts to v4.7. That would have been a long time ago, and it's hard to guess what it could be, and it'd require a bit of analysis to figure out. I'd recommend migrating to a new instance; you can use Feed Importers in the latest version to pull all the content from your existing instance. It's possible to bypass the errors with inedosql resolve-error --all but I really wouldn't recommend it, since it could lead to more problems. Cheers, Alana

@mcascone said in Proget: retention policy for branches in a package: This means mybranch and mybranch2 can be reduced to mybranch2. Sorry but wouldn't this be the reverse: *mybranch* will match *mybranch2*? What I mean to say.... because it's an AND conditional, the *mybranch* is effectively ignored. Everything that matches *mybranch2* will also match *mybranch*, but the opposite isn't true. E.g. mybranch1 won't match both conditions. @mcascone said in Proget: retention policy for branches in a package: in this feed, delete matches of 'mybranch', except the latest 3 versions of those matches, which would only impact the versions matching mybranch and leave all other non-matches untouched; Correct. And do note that you can set retention policies to run in dry mode, where nothing is deleted, to verify it's the behavior you want.

It seems to work normally now with the homepage setting to none. The default category is support. So I'm happy! Thanks!

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 :)