At the moment the MsTest extension requires a test file be specified. However, we do have the code public for this extension: https://github.com/inedo/bmx-mstest If you're interested modifying the extension quicker than we can, check out: http://inedo.com/support/tutorials/cloning-and-patching-an-inedo-extension As for email, that might require more customization. You can instead have users sign up for the "Execution Completed" notifier which will link them to the test results.

Unfortunately that is a limitation of the v3.X line of BuildMaster - releases were ordered and meant to be built on top of each other, e.g. once version 5 goes out, it is meant to encompass everything up through v5. If you were to upgrade to the 4.X line (make sure to read all the upgrade notes first), then you can actually re-order releases as necessary, and allow other advanced workflow options.

Fixed! The issue was that the subversion configuration was pointing to its local svn.exe instead of the one we had installed on the server. I had to change the 'Path to svn client' field to point to our copy of svn.exe. Thanks again.

Thanks; we were able to reproduce this, and will revert it to old (correct) behavior in a maintenance release.

Waiting might be best for me. <-not so good with object oriented languages. I think it would be a great additions to be able to access the many types of Variables. (application, release, build are the 3 types I use, not sure about the rest of your client base) I expect my end result would look like: $ReleaseVariable(${ReferancedApplicaitonID, ,${ReferancedReleaseNumber, FolderNumber) Wow that just got crazy. Think it can handle passing in functions to find a variable? I am not in a rush, I just want to reduce the risk of problems. And because 4.3 did a major change to the database my built-in-house reports would have to be redone, so I am being lazy with updates. Also this solution would be able to consolidate some of my shared plans that each call different variables, if I instead ask for a variable by passing in the environment like this: $Appvar(${AppID}, ${EnvName}Server) I can have the same task work on all my environments. Thanks, Dan

SQL patch received and applied, thanks. The Manual action step is now working again. The log file detail shows in the same window using IE but only show as [View Full Log] in Firefox (no new tab or window is opened)

Hi Tod, Thanks heaps, that makes sense to me. Thanks for the quick reply. Regards, Daniel.

It looks like this method was removed as part of the 4.3 executor refactoring; but it will be replaced in a maintenance release (shipping this week). If absolutely needed sooner, you can query the [BuildExecution_ActionGroupActionVariableValues] table direct or via a stored proc.

Just to follow up, got some help from the inedo folks and we discovered that the server hosting the sql server database had its system clock slightly off which was causing the delay till the start of execution.

It sounds like this is a bit of a hack; when an application component is deployed to a production environment, it's status should be represented as "Deployed". You can purge releases if needed using the Releases_PurgeReleaseData API/Sproc method.

For reference, this also happened on another user's machine, and the following entry was found in the event log around the same time: Windows detected your registry file is still in use by other applications or services. The file will be unloaded now. The applications or services that hold your registry file may not function properly afterwards. DETAIL - 3 user registry handles leaked from \Registry\User\S-1-5-21-1409082233-789336058-1343024091-27055: Process 2940 (\Device\HarddiskVolume3\BuildMasterAgent\Agent\_tmp\bmtcpagent.exe) has opened key \REGISTRY\USER\S-1-5-21-1409082233-789336058-1343024091-27055 Process 4388 (\Device\HarddiskVolume2\Windows\System32\conhost.exe) has opened key \REGISTRY\USER\S-1-5-21-1409082233-789336058-1343024091-27055\Control Panel\International Process 2940 (\Device\HarddiskVolume3\BuildMasterAgent\Agent\_tmp\bmtcpagent.exe) has opened key \REGISTRY\USER\S-1-5-21-1409082233-789336058-1343024091-27055\Control Panel\International

As far as I'm aware, this particular issue has already been resolved. Can you post a new question with the same details? For some quick suggestions though, does echo $ApplicationName work as expected? Is the application configuration to use new variable support (Settings -> Application Settings)?

Currently this is supported through the API, but not via the triggered builds. We will add the ability to specify a build number for URL triggered builds in the final version of 4.3 due out end of next week. You can already specify variables for URL triggered builds by including them as part of the query string, e.g. http://buildmaster-server/trigger-build?id=1000&myVar1=value1&myVar2=value2

The main strategy is to have one application per website, and then either: Pull the core 30 projects and build them as part of each website application, you can use shared/linked action groups for this to make it a little easier. -or- Build the web core files in their own application as you've started to do it seems, and store the build output as an artifact, then import that deployable in each of your website applications. This allows you to deploy the artifact with the core files in it before you build one of your web applications. We've named this option the "Core Version" pattern, and you can find a specific example of it here: http://inedo.com/specifics/buildmaster-extensions I will also note that deployment plans are getting a nice overhaul in the upcoming BuildMaster v4.3, it will be much simpler to share deployment plans across applications so managing plans for this scenario will be even easier.

There is a "purge artifacts trigger" that you can set-up that will delete artifacts from Rejected Builds, either immediately or once the release is deployed. We do have it on our roadmap to have artifact retention and clean-up policies as a more advanced feature.

NOTE : BuildMaster has Retention Policies which are strongly recommended, rather than manually purging data That being said, you can use the same strategy to delete from that table that you used for log entries: BuildMaster 4.2 and earlier: SELECT TOP 100 * FROM BuildExecution_PlanActionVariableValues --DELETE BuildExecution_PlanActionVariableValues WHERE BuildExecution_PlanAction_Id IN (SELECT BuildExecution_PlanAction_Id FROM BuildExecution_PlanActions BEPA INNER JOIN BuildExecutions BE ON BE.Execution_Id = BEPA.Execution_Id INNER JOIN Builds B ON BE.Application_Id = B.Application_Id AND BE.Release_Number = B.Release_Number AND BE.Build_Number = B.Build_Number WHERE B.BuildStatus_Name = 'Rejected') BuildMaster 4.3 through 4.9: SELECT TOP 100 * FROM BuildExecution_ActionGroupActionVariableValues --DELETE BuildExecution_ActionGroupActionVariableValues WHERE BuildExecution_ActionGroupAction_Id IN (SELECT BuildExecution_ActionGroupAction_Id FROM BuildExecution_ActionGroupActions BEAGA INNER JOIN BuildExecution_DeploymentPlans BDP ON BEAGA.BuildExecution_DeploymentPlan_Id = BDP.BuildExecution_DeploymentPlan_Id INNER JOIN BuildExecutions BE ON BE.Execution_Id = BDP.Execution_Id INNER JOIN Builds B ON BE.Application_Id = B.Application_Id AND BE.Release_Number = B.Release_Number AND BE.Build_Number = B.Build_Number WHERE B.BuildStatus_Name = 'Rejected')

Wow, what an incredibly fast response. Thanks

We don't have export capability for those other items just yet. Does purging the logs as per http://inedo.com/support/questions/1826 not help clean out 90%+ of the space? The log table is the one that typically fills the BuildMaster database. There are some other tables that could also contain a lot of data depending on usage, those being: BuildOutputs (if you generate and store reports with every build) BuildTestResults (if you run unit tests during builds) EventOccurenceDetails & EventOccurences (if many users are constantly using the software) The first 2 can be purged for rejected builds, and the event occurences can be purged entirely if that data is meaningless.

We believe that it should not because it's most likely a mistake to specify a directory that doesn't exist as the working directory since presumably there could be files to work with, etc. in that directory. As you mentioned, the workaround is to create the directory before this step. I would just use mkdir in a PowerShell or Bash script.

You can't run BuildMaster on MySQL, but it is relatively easy to move it to a different SQL Server -- see Backing-up and Restoring BuildMaster