Hello Jeff, There is currently a bug in the FeedCleanup task for Docker feeds. PG-1030 has been fixed for the next version of ProGet, but until then, disable the FeedCleanup task for any Docker feeds in /administration/scheduled-tasks.

It seems like something changed in security settings - Publish Packages task got "private" scope. I droped "Publishers" and added them again, scope has been changed to "all feeds" and problem gone! Seems it's an upgrade bug because the scope option can't be set in free version...

The npm search command has been broken in npm for some time, as it downloads the entire package index and searches it locally. Due to the size of the index on npmjs.org, this stopped working for a lot of people due to npm OutOfMemory errors and various other issues. Because of this, they deprecated this form of searching in the npm client in favor of a new search API, but it seems that only npm 4+ actually uses the new API. Indexing all of npmjs.org also caused a lot of problems for our users due to the sheer amount of data involved, so we dropped indexing of any registry that supports the search API. Local packages are still returned in the /-/all endpoint, since this doesn't require the same server overhead, which is why you are still seeing those packages. Basically, you may want to try the new npm client, or just stick to searching on the web for now.

Sorry for the confusion... I think those should be listed as "internal only" methods, and not on the API page. Anyway, the Native API can only be used for metadata. So you won't be able to use it in this manner.

UPDATE: this has been updated in PG-1632 __ Hello Jonas, Deleting images isn't in the native API because the stored procedures only delete metadata, but if your CI server has access to the database ProGet is using, you can run the stored procedure to delete the metadata for the image and ProGet will automatically delete the files whenever the FeedCleanup scheduled task next runs. Assuming your docker image is named proget:443/foo/bar/baz, the foo feed has ID 42, and the digest for the version of the image you want to delete is f52fbd32b2b3b86ff88ef6c490628285f482af15ddcb29541f94bcf526a3f6c7, this SQL statement will work: EXEC [DockerImages_DeleteImage] /* Feed_Id */ 42, /* Repository_Name*/ 'bar/baz', /* Image_Digest */ 'f52fbd32b2b3b86ff88ef6c490628285f482af15ddcb29541f94bcf526a3f6c7' GO If you don't know the digest, https://proget/api/json/DockerImages_GetImages?API_Key=[your API key from /administration/api-keys]&Feed_Id=42&Repository_Name=bar/baz returns metadata including Image_Digest and Published_Date, and https://proget/api/json/DockerImages_GetTags?API_Key=[your API key from /administration/api-keys]&Feed_Id=42&Repository_Name=bar/baz returns metadata including Image_Digest and Tag_Name.

Please make sure that the Amazon extension is downloaded. You can see which extensions are installed on the ADmin > Extensions page. When the service is loaded, the extensions are unzipped and put in the foloder you referenced.

Hello Jason, It looks like the npm registry started returning empty responses about a week ago. It looks like they're having caching problems. ProGet 4.7.8 and newer support the npm search API, so indexing isn't needed to search the npm registry, or you can wait for npm to fix the problem on their end.

We had switched to IIS hosting of the web site, and so the solution was to first stop the web site in IIS Manager before running the installer.

I would also try to upgrade your new server to 4.7.6 as well, because I really can't think of anything in the ProGet software that would yield this behavior. The file's bytes are simply written to disk as they are received using streams and async methods. Moreover, we test with large packages and have a lot of users who have large packages, and none have reported issues.

Hello Peter, Thanks for the bug report! I was able to reproduce the problem, and it will be fixed in the next minor version of ProGet (4.7.12). PG-1029

Regarding the database migration, we don't have an export/import function.. but you can just recreate the feed and use the bulk import path for your exisitng packages.

Glad you were able to get a little further... I've added this to the our public issue tracker as PG-1026. It's currently classified as unscheduled, but I imagine it will make it into the next release.

According to the mvn deploy documentation, you'd need this in the POM file for the project: <distributionManagement> <repository> <id>myproget</id> <name>My ProGet Feed</name> <url>http://progethostname/maven2/feedname</url> </repository> </distributionManagement> If the feed requires authentication, you also need this in settings.xml (the <id> values have to match): <server> <id>myproget</id> <username>username</username> <password>password</password> </server> If you want your snapshot versions deployed to a separate feed, you can add a <snapshotRepository> to <distributionManagement> in the same format as <repository> above. After that, the command is just mvn deploy to upload the package to ProGet.

It's been quite a while since I last used Maven, but I think the POM file would look something like this: <project> ... <repositories> <repository> <id>mysite</id> <name>My Site - ProGet</name> <url>http://www.mysite.com/maven2/mf</url> </repository> </repositories> ... <dependencies> <dependency> <groupId>apackages</groupId> <artifactId>new-packages-jar</artifactId> <version>0.0.1</version> </dependency> </dependencies> ... </project>

Hi, Krzysztof G., did you ever managed to integrate both Octopus and ProGet? Using just the ProGet URL we can "connect" but it replies with an empty list. Is there anything else needed? Maybe a registry path?

This is what NuGet is designed for; I recommend to check out documentation at NuGet.org on how to ge started.

Maven repositories are traditionally just file systems organized by convention, either local or exposed using a simple web server, so a lot of repos get this "for free" by just enabling directory listings for URLs. ProGet works a bit differently and simulates some of the traditional maven structure, so it's not necessarily trivial for us to implement this; that's not so say we can't do it, just that it wasn't deemed essential. While I don't think that this is formally part of any maven specification, a lot of other repositories do it, so it's been on our "maybe" list for some time; we just haven't had a lot of interest in it so far, so it hasn't made it onto the roadmap. We'll reevaluate what it would take to do it, and add it to the roadmap if we think it's something we can work in soon.

This has been address in v4, but asa workaround, just use the "Browser tools" to edit the text on the page, and unhide the edit buttons.

That's actually only a display issue with 4.7.10. The endpoint is still /maven2/. We've logged this as PG-1022.