We don't, so that means probably in the next week or so; unfortunately this has not been a high-enough priority issue to trigger a maintenance release. Once we have that one, we can do another docker/linux build quite easily.

Thanks Alana, issue has been fixed now.

Ah, ok, that would definitely be an issue. I've added another change [PG-449] to add a new property called BaseUrl. It should be out in the next maint release.

Last time it happened after 2 days (or maybe less, but that's when I noticed), but now it has been running for 4 days and it still works. We have been using the NuGet feed a few times during those 4 days. I will keep monitoring it and report back if I find anything!

Hi, please refer to https://docs.nuget.org/create/creating-and-publishing-a-package and https://docs.nuget.org/consume/command-line-reference; just make sure to specify the ProGet URL for the --source option

There have not been any updates that would have impacted this recently, or known issues like this. Unfortunately, there are a lot of things that can cause this, but one of the most common ones is one or more agents with a bad network connection. Because agent communication is pooled, and I/O is a bottleneck, often time one server is waiting for another to finish, sometime it can be difficult to tell which specific agents are causing the problem. The easiest way to find problem agents is this... Stop the BuildMaster service from the Web UI, then Start it You will see a bunch of "AgentUpdaterChecks" running simultaneously These should take seconds at most to complete Try to identify ones that are taking too long Once you've found agents that never seem to complete the check, stop the service, then disable those servers (Edit Server > Active) Go back to the beginning Once you isolate the servers, it should be relatively easy to find them out.

If you just either use the NuGetFeed constructor that does not take credentials, or set the credentials parameter to null, then it will attempt to use Windows Authentication for the current user.

Thanks, it works (after we updated to the latest version).

I think your best bet would be to make a custom extension that runs the test and records the results. The junit extension contains the "Execute jUnit Tests" action, which primarily does three things: execute junit itself parse the xml-report file record the test results in BuildMaster You've accomplished Step 1 already with your script; I assume, your PowerShell script is just invoking an .exe? What you need is Step 2 and 3. You can see these in action here: https://github.com/Inedo/bmx-junit/blob/master/JUnitAction.cs#L98 Another Action to look at is VSTest: https://github.com/Inedo/bmx-mstest/blob/master/VsTestUnitTestAction.cs

The "Proxy Configuration" page does not (currently) send an agent string; apparently, maven.org will return a 403 errors without an agent string, so you will get an error if you attempt to visit the maven central index (https://repo1.maven.org/maven2) from that page. However, the FullMavenConnectorIndex task (which is schedulable / runnable under Admin > Tasks) does send an agent string, and maven.org does not block that request. If you are getting a 403 during that task run, it's going to be coming from your intenral proxy server, not maven.org.

Only per feed, and that requires the Enterprise edition. The free edition only allows system-level privileges.

This issue has been resolved in ProGet 3.8.1.

There's nothing special that ProGet is doing, it's effectively just inserting a SRCSRV stream into the pdb, exactly as pdbstr would. I'd also check out #3061, and specifically http://techblog.dorogin.com/2012/09/troubleshooting-debug-symbols-indexing.html

Note this response will be handled via an email chain and will require either a new SVN extension or require a change to BuildMaster to resolve. Also see the following thread on GitHub: https://github.com/Inedo/bmx-subversion/issues/9

This is no longer a supported feature. Very few customers used it, and it caused a lot of headaches when it was used. We may consider adding it back; in the meantime, you can write a script to retrieve packages from a connector, and copy them to the drop folder.

The "load from" options were removed in v4.5, I'll add a note to remove that from the tutorial. Updating the screenshots is already on the list to update as well.

Currently, we only support the synchronization / replication of specific feeds using the MyGet sync feature. We may offer a ProGet <-> ProGet feed sync feature in the future, but there's not a lot of demand for it.

ProGet on IIS is only supported as a root level web site of IIS - it cannot be a virtual directory of another application. If this is not an option, you'll have to go with the built-in web server option.

Ah, I see. We have been able to reproduce this - it looks like a regression in handling the feed-specific npm adduser URL. We've also always handled the /siteroot/-/... one as well because npm used to always use that regardless of the repository URL. I think that changed some time around npm 2.7 when we added the second handler. Regardless, we've already fixed this internally (again), and will be releasing the fix as part of ProGet 3.8.1 likely some time tomorrow. Thanks for the help!

For all lookers, answer chain above resolves the question Awesome, thanks for the great support. I'll look forward to the Extension, in the meantime I think I have enough going now to generalize for the rest of our environment. Thanks for the assistance, and as I mentioned -- the product so far is excellent and we will definitely be purchasing the Enterprise as soon as I get quotes back! ;-) Cheers!