Hi Damian, I completely that you shouldn't have to install a client to use TFS. Unfortunately, only the most recently (v2015) libraries are licensed for redistribution, and these libraries require .NET 4.5, whereas BuildMaster v4 only requires .NET 4.0. These libraries also don't seem to connect to earlier versions of TFS unless VS2015 was actually installed; it's a bit frustrating for us, and other ISVs as you can imagine. We have requested a redistribution license of the earlier libraries, and we can continue to explore getting it to work on our end, but it's not at all trivial. The currently solution is to GAC the assemblies yourself or to install the TeamExplorer 2013 client, which does GAC these assemblies.

Thanks Tod. I have run the provided SQL and can confirm that the View Purge History page is now working again. Cheers.

The service must be able to restart itself and overwrite its own files.

Hmm, they are not different. Privileges are checked in the same manner regardless of the action that's being edited. If you're running into an error, it may not be related to privileges; perhaps send in some screenshots / more details to support at inedo dot com? If the plan is a global plan, note you need the [Plans_ManageGlobalPlans] task instead of the [Plans_ManagePlans] task.

If you want multiple builds of the same application going at the same time, then you won't be able to use the default, $CurrentDirectory. I would instead use a directory like, $ApplicationDirectory$ReleaseNumber$BuildNumber. However, once you deploy a release, you may want to clear $ApplicationDirectory$ReleaseNumber, otherwise you will end up with a lot of disc space used.

Oh, it works now. Thanks a lot, Alana!

This requires the [Events_ManageOwnNotifiers] task.

SFTP essentially works over SSH; BuildMaster's SSH-based agents utilize SSH and SFTP to run scripts, actions, and transfer files; so, you can just set-up an SSH agent, and then transfer files as needed. FTPS, on the other hand, is completely different; it's basically FTP over SSL, so you can just use the FTP extension for that.

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

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.

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.

The reason you have to Get Latest is because otherwise if you built straight from the BuildMaster-managed "ScrRepo" directory, there would be artifacts from the SCM tool also included (for git, .git files), and other times added files from the BuildMaster build steps that you wouldn't want stored with the repo. Once you "Get Latest" somewhere, you can operate on a fresh set of files to perform whatever build tasks are necessary for deployment. Note the "Get Latest" action will essentially perform a clone or pull from BitBucket, then copy the files to the source directory of the action.

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

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.

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!

Yes, run the Admin Tool from the start menu.

You can move BuildMaster from one server to another using the backup and restore instructions. However, I would suggest using the built-in retention policies to purge old items instead of that script.

Yes. Currently different versions of our websites get deployed to the server to a directory based on the version number. Was interested in just changing the directory the website was pointing at after the artifact was deployed. We currently do have a builds/deployments using a bunch of PowerShell scripting but it is getting challenging to maintain. Thanks for pointing out the Windows Extension.

Your best bet will be using either a Delete files action, or simply just the Transfer/Synchronize files action, along with some negative/exclusionary masks. For example... * !images !cache !web.config