Hi @udi-moshe_0021, Do you see any errors logged in the diagnostics center in ProGet? I did a test of pulling the image using Docker and the Pull Tag button in ProGet and they both worked in my case. I'm thinking you might be rate limited by docker.osgeo.org in your ProGet instance. Thanks, Rich

Hi @v-makkenze_6348, Glad to hear it! Thanks, Rich

Thank you so much!

Hi Alana, This seems to work for what I am trying to accomplish. Thanks! Scott

Hi @parthu-reddy , If you can provide my with some step-by-step instructions (reproduction case), then I can see if if there's a bug in ProGet. However we can't really change the "license file is embedded in the package file" technical requirement. That said... using custom licenses for blocking package is definitely inappropriate. Please do not do that. It will cause you headaches and probably business disruptions later. There are already tools to prevent users from downloading packages from ProGet, this is not how you want to do it. The easiest solution here is to align the security team's understanding/expectations align with reality. You don't want to try to configure ProGet in unrealistic ways that will lead to actual problems/risks. I suspect the security team is conflating "vulnerable packages" with "malware and viruses", so it'd be best to take this opportunity to educate them on how packages / ProGet works. ProGet can prevent users from downloading certain packages, but vulnerable packages are freely available on the internet for download. A vulnerable package is NOT some a "virus in a lab that can escape" and infect a system A package is just a library and cannot run on its own If a user has a copy of vulnerable package, they can't use it to "hack" a system with it nor will it cause any harm Vulnerable packages simply shouldn't be used as building blocks in your own applications Thanks, Alana

Hi @parthu-reddy , This hasn't changed; to "Set Package Status", you need to first Pull the Package to the feed. From there, you can a compliance rule override of Always Block or Always Allow Downloads. Thanks, Alana

Hi @caterina, I'm sorry about this. There looks like there was a conflict with another notifier change. I have created a new ticket, PG-2933, to fix this and it will be released in the next maintenance release. Thanks, Dan

Hi @arose_5538, We just released ProGet 24.0.31 that has the fix included for this so you do not need to specify those extra environment variables. Thanks, Rich

Hi @pratik-kumar_8939 , Unfortunately Nexus has a very limited API, which is why the so the import isn't working (404 error - not found). Basically, it doesn't implement the "catalog API" that allows all artifacts/packages to be listed. However, you can use a file-system / drop-path import after you extract the files from Nexus Thanks, Alana

Hi @v-makkenze_6348 , This error was related to an error on our end - basically there was some bad data in the package that the InedoHub downloaded, and it caused the installer script to crash. We fixed the package on our end, so reinstalling normally should work now. Cheers, Steve

Awesome, thank you so much!

Thank you for your guidance Dean!

Thanks ! Works as expected... as always :)

Hi @infrastrcture_6303 , We've had one other user report this, and unfortunately it's a bit complicated behind the scenes. ProGet 6 allowed npm packages to be uploaded without a @ in the scope, which meant that if you used a non-npm client (your own script, etc), you could have "bad data" in the database. We did not anticipate this data when doing the ProGet 2023 datamigration, so the bad data was brought over. We don't have a means of fixing it, and it would take a nontrivial amount of time to do that - so as a free user we can't really put in that time. We do plan on a cleanup task ina few months that will take care of this automatically. If you're comfortable with SQL, you may be able to fix it yourself (that's what the other user did), and it invovles a figuring out some queries around the PackageNameIds table. Another alternative is to setup a new instance of ProGet 2024 and then just import the packages from disk. Thanks, Alana

Hi @jfullmer_7346 , I was able to reproduce this, and we will fix it in an upcoming maintenance release (PG-2920). This came from a regression in 2024.28, with some other NuGet feed changes. Cheers, Alana

Hi @procha_8465 , I'm afraid we'll need a bit more information here to help you. There are a lot of changes between ProGet 5.2 and ProGet 2024 and between older/newer versions of the npm client. If you can put together a reproduction case, ideally on a new instance of ProGet 2024, that'll help us determine what you're trying to do and how to help. -- Dean

Hi @f-medini_8369, Here is our documentation on how to use Prometheus: https://docs.inedo.com/docs/installation/logging/installation-prometheus -- Dean

Hi @pratik-kumar_8939 , ProGet does not require two different feeds for this, and we would generally recommend putting them in the same feed. If you wish to have the artifacts intwo different feeds, then you can just create different feeds and name them how you'd like. Thanks, Alana

Hi @simon-marriott_1201, If you haven't seen it already, I'd check out How Files and Packages Work in ProGet for Artifactory Users. Long story short is, you should consider a more modern approach than the Maven-based file/folder that Artifactory uses. Many have found a lot of success with Universal Feeds & Packages. We don't maintain a TeamCity plugin, but it's really easy to create, publish, deploy packages using the pgutil command line (i.e. pgutil upack create); see HOWTO: Create Universal Packages Hope that helps! -- Dean