I agree that it is a poor solution, but we do not have very many good solutions for this. Docker itself does not support prefixing private repositories; everything is assumed to be hosted in the same manner as the public registry (ie, absolute URL path from the server root), and assuming all /v2/ requests are Docker without some other declaration of intent in the request didn't seem good either. That said, if there's no collisions with anything else using that URL, we can change the default behavior.

Please upgrade to the latest version of ProGet; 4.3.1 is outdated.

Answering my own question: all one needs to so for this is to remove the Anonymous user from the users allowed to "View and download packages".

Note that these are different issues. Please upgrade to the latest ProGet to resolve this and the other issue. As of this post, that's 4.7.8. However, we do release often so if another one comes out before then, pick that one :)

This can be found in the lower-right of any page in the software.

You can configure this via the "BaseUrl" setting in the Admin > Advanced Settings configuration option.

This package indicates that the package you are adding is in an invalid format. If it's a nuGet feed, you must upload a nuget package. If it's a universal feed, you must upload a universal package format.

This seems to be fixed as of the Docker image containing ProGet Version 4.7.14. The Docker image hash is: b7a3d6595c21d34997b4cbe6da9187801f410f17bff8e84228711bf29396a6ab pulled on 9/6/2017

Ok I figured out what I was doing wrong. I was setting the URL in build.gradle to: http://<user>:<password>@proget-server But it should look like this instead publishing { repositories { maven { credentials { username "$mavenUser" password "$mavenPassword" } url "http://proget-server" } } } With the mavenUser and mavenPassword being defined in ~/.gradle/gradle.properties

This is on our list for an upcoming maintence release, and may get implemented in the next one. you can check the status of it at PG-1001. https://inedo.myjetbrains.com/youtrack/issue/PG-1001

There are many guides and ways to do this, please search "adding a maven artifact to a repository". Here is one such example: https://maven.apache.org/guides/mini/guide-3rd-party-jars-remote.html

Version 1.1.0 of the upack command line tool is now available from http://inedo.com/support/documentation/proget/reference/upack. The chocolatey version has been submitted and will be available once it's approved.

In this case, you will need to give the "Anonymous" access to push packages to the feed. You can configure this from Admin > Tasks.

Final results for curl -X PUT... I was able to change C:\Program Files\ProGet\WebApp\Web.config (yes, my server is on Windows 10), and increase the transfer size from 1Gb to 3Gb I then restarted the ProGet Web Service I then tried to upload a zip file 2.02Gb in size..and, it worked.

Apparently I was an idiot and couldn't do basic auth correctly, because once I did that correctly it worked fine without anonymous access involved. I am using Java 8, and the Authenticator class to set the authentication on my URL globally. Hope this helps the next person coming along.

I'm on ProGet Version 4.7.8 (Build 4) (locally hosted, not on EC2) and I'm able to upload universal packages to an S3-backed feed using the upack.exe tool with both the latest published release of the Amazon plugin and a debug build from source code. Can you still reproduce the error on the latest version of ProGet?

The endpoint is not yet deprecated. This error means that connector url is incorrect, npmjs.org is returning an error, or you have some proxy server blocking the request in between ProGet and npmjs.org.

This appears to be an internal Java error, indicating that the package cannot be bufered due to low process memory. So, I would increase the memory of your Java/Jenkin instance. You can use the -Xmx1024m option to give 1GB of memory to your application. This will increase the amount of data you can store in memory.

The npm endpoint to get all packages is /-/all, so in your case: http://dr-tj-pkgsvr01/npm/npm/-/all

Tried stoping the service that was tying up port 80. No help.