Awesome! It looks like the API is working without a hitch in powershell. At this point, we probably have enough to to start with and a few angles to test. If we have any issues with the API or procs, we'll come back here. Thank you!

This can sometimes happen when the cookies are not cleared properly after an upgrade. Try flushing your browser cache and clearing your browser's cookies, then visit the BuildMaster site root, e.g. http://buildmasterinstall.corp/

Wow, that was quick! Thanks!

Thanks but I've had to revert back to 2.6.3 for now after spending most of the day trying to get the update to work. Will try again with 3.1 when it's available.

I've installed 3.0.6 successfully now (I think).

Not currently; that information is configured at an extension level. We do have a feature on the backlog that would allow for multiple extension configuration profiles, but that's not schedule for a specific release yet. In the mean time, your best bet would be to modify the extension (we can provide source code) to bring these peroperties to the action-level.

I'm not sure what you mean by distributed tests for MSTest, but pointing the MSTest Action at the configuration file is the way to go if you already have one. As for the batch file problem, what does your action configuration look like to try to run the .bat file? Is it set to run on the correct server? Does the account running BuildMaster have access to those paths? It's also possible that when you're running locally on the target server that you have the MSTest directory in your PATH but the BuildMaster account doesn't. That being said, is there a problem running the MSTest action as opposed to this batch file? It will be better integrated into the logs if you use that instead - the batch output will only give you stdout/stderr as opposed to an individual test breakdown.

It looks like you're currently on 2.6. You'll need to upgrade to BuildMaster 3.0... we made a breaking change to the API/SDK and are no longer supporting our extensions written for 2.x.

We do use the specific paths under the project root. The issue still occurred, but we altered our labels to have a text precursor and now it works. It appears to be an issue with mostly numeric labels and TFS. If two apps in the same root project happened to get similar release numbers... then it bombed.

Looks like this is a bug in the text :-) Should be "," separated.

Karl, thank you for the quick reply. We have 13 separate projects in just 1 of our solutions, so I was avoiding the tedious job of setting up an action to build each individually. What I ended up doing, and making work, was to just execute mstest.exe on the command line without the /p:OutDir parameter, using an "Execute Command Line" task. Not sure how that will play with the tasks that come after the build, but I suspect as long as I manage my paths correctly in the subsequent actions, it should be OK. Thanks again for the assistance.

The user that connects to SQL Server needs to be granted the BuildMasterUser_Role; this role is created as part of the database creation. No additional roles or access is needed.

Some providers, including the TFS provider, do not include the branching functionality. Generally, our branching actions are only implemented for providers that don't allow labeling (such as SVN which only allows tagging). One way to branch is to use the "Execute Command Line Action" against tf.exe command line utility to perform the branch with the appropriate arguments (http://msdn.microsoft.com/en-us/library/d73s8b27.aspx). Since our providers are extensible, we could always add this functionality to the provider. We prioritize features like this based on usage, so if you could send your use case to support at inedo dot com we'd be glad to help further!

It is working now that I set the Action Group to "all deployables". I still can't use the specific deployable though. I copied the named deployable through my steps and it fails... but the generic works just fine.

Anything that can be built via a command line interface can be built in BuildMaster using the "Execute Command Line" action with the appropriate arguments. Because actions are extensible, you (or we) could also write a first-class action named something like "Build Android Project" with only the fields generally necessary to build an Android project.

It looks like for some reason one of the subdirectories beneath C:\Code\Build is not getting cleared. This could happen if there is either a file that cannot be deleted due to the directory's security attributes or a hidden file contained in one of the directories. It may be helpful to enable the "Log individual entries" option to troubleshoot this problem - that way you should see which directory it gets stuck on.

It turns out the license key request service was down, thank you for reporting this. It should be up and running now. If this happens in the future, trial and free license keys can be obtained by creating an account on the https://my.inedo.com website.

Generally this is a result of the web application domain account lacking sufficient privileges. Ensure that the account that the BuildMaster web standalone service (for the self-hosted web server) or the IIS application pool is running under an account that can query service statuses on the machine.

If you run the command: sc config inedobmwebsrv depend= / for the web server or: sc config inedobmsvc depend= / on the server with admin privileges, the dependency should be removed.