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

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

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.

Well, the only code path that will yield that error is if System.IO reports that the file requested is not on disk. The most likely cause of that is that the file is not actually there at the time (obviously), but that might be because anti-virus quartanteed it, a file server didn't replicate it, or something? So, I would try to find what might be causing that file not to be there. The only way that BuildMaster will delete a file (but not the record) is a retention policy.

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

Correct; that, and the API key, are what get sent over.

Correct. Output variables don't need to be specially declared. However, the next version of the Windows plugin for BuildMaster and Otter will add support for [ref] parameters as output variables in the editor.

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?

Thanks. That of course fixed it.

Thanks Tod, I guess I was overly enthusiastic for this feature ;)

MaxResponseLength was missing a ScriptAlias. It'll be fixed in the next release.

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.

This has been added as BM-3004, and is currently scheduled for 5.6.10.

This has been on the list for a little while, but I finally made a github issue for it. We'll get it soon! https://github.com/Inedo/inedox-inedocore/issues/22

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

Just as a follow-up, we are going to clarify this behavior and "fix" it to be more like your use-case, see: http://inedo.com/support/questions/6290#inline-post-6291

The problem here is that there is not exactly 1 environment in context. I'm guessing this is an orchestration plan? Configuration plans will already bring in the environment context if there is exactly one environment. The way this will be solved (targeted for v1.6, but may appear earlier in a v1.5.X maintenance release) is by the following rules: Context will solely be determined from environment associations of servers (this changes the current behavior which relies on orchestration jobs being targeted at an environment in order to bring the environment into context) Parent environments will only be considered for user permissions and variable resolution If there is not exactly 1 environment applicable to the current server in context, $EnvironmentName will result in an empty string (so the same as you're seeing now) We will add @EnvironmentNames which will resolve to a list of all environment names in context (including an optional parameter for including/ignoring parent environments)

We have responded to this via the ticket you submitted, can you verify that you received it? Today we switched to a new automated ticketing system and I want to verify whether you received an email update or not from the system. Here was the response: In BuildMaster v4, these are configured on the Admin > Extensions > Source Control Providers page for the specific provider in the URL of the remote repository itself, e.g. https://user:pass@example.com/remote.git

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.

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