That sounds great! I'll mail you some testcases for reproducing the issues we ran into shortly.

not currently, but it's definitely on our roadmap to do a caching in a similar manner

Tod, I have resolved my problem. Where I select "server" on new git repo setup, I shouldn't have chosen the target server, but the server, where buildmaster (and git) is running. This confused me. Thanks for attention, Milan

Hi, Same question here: http://inedo.com/support/questions/3738. The git repo itself is worth caching for enterprise needs. Actually our developers checkin in the bower_components directory into their git repos, because of the "fear" that the public git repo is getting unavailable. As I can see, https://www.npmjs.com/package/private-bower has this feature. Regards Marco

Thanks for the feedback. The HttpModule was not the cause. I just had to configure the NuGet.config credentials correctly in %ProgramData%\NuGet\Config\NuGet.Config, which is machine wide rather than user specific. I will distribute this configuration to all developer machines using an Active Directory Group Policy.

So I wanted to respond on here, I wasn't quite sure what to do with the information but I wanted to proceed. What I did was the following: Forked the GitHub repository Modified the TfsBuildActionEditor to have a Checkbox for [Validate Build Status] Modified the TfsBuildAction to use this and created a ValidateBuild function If the Check is selected it sends an error and pulls the Build Errors from the Build Details and displays them. I am not sure if this is something you wished to add so I did not submit a pull request. I could do so, but this can be considered answered. The whole point being that we didn't believe that "Create TFS Build" goal was met during a build failure, and there should be a way of validating that this actually did occur. If a build controller fails then a build was not created, or was partially created, and thus the Action needed to be able to reflect that. This also helps keep the CI running smoothly since it now becomes very apparent why a build broke and does not actually break test. Hope this helps anyone else who hits that! Consider this closed.

Thanks Philipp i will findout the script to delete the files.

I have found the solution ... Set the Property "UseIntegratedWebServer" to False in the Advanced Config when use IIS. The solves the problem

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.