Hi Ryan, That's definitely unusual! There should definitely be a bunch of logs here, especially showing the exact SCM command-line command that was run. So, something quite unexpected is happening... What source control provider are you using? And also, what happens when you test connection? Can you share the configuration of the provider (a screenshot should be ok), you can send this to us at support - at Inedo dot com.

the execute command-line action will run a process directly. So, if you run the java.exe as the command-line action, and then specify those arguments, it will work in the way you'd like

I've managed to implement this using the BuildMaster API. The combined workflow now looks something like: Saturday 9:00PM (Prior status): Release 1: Hotfix Workflow Release 2: Deployment Workflow - Pre-Staging Saturday 10:00PM (Latest Release Deployed): Release 1: Marked as Deployed Release 2: Deployment Workflow - Deployed Saturday 10:30PM (New Release Created): Release 2: Deployment Workflow - Promotion Release 3: Deployment Workflow (No Build) Saturday 11:00PM (Automatic Build Triggers): Release 2: Hotfix Workflow Release 3: Deployment Workflow - Pre-Staging One of the steps executed during the Pre-Staging workflow (initiated as soon as a build is created) is to call a script which uses the API to first reject any active builds from the previous release, and then update the release with the new workflow. API Steps: Get Builds for previous release with Builds_GetBuilds. Check for any builds with Current_ExecutionStatus_Name == "Executing", fail if there are. Reject all builds with BuildStatus_Name == "Active", using Builds_RejectBuild Update Release with Releases_CreateOrUpdateRelease, setting the desired Workflow_Id.

Please note a lot of these errors are coming from third-party tools, like svn or msbuild, so it's not possible to know precisely how to fix it without knowing more information. Unfortunately it's really difficult to diagnose or provide further troubleshooting with the information you've provided so far; if you paste/share the entire logs, we might be able to provide more insight. Please see KB#1052 - Troubleshooting Failed Builds and Deployments for more help on how to diagnose.

This should be fixed in the 5.0 beta, which we will probably have available for download this week. Basically, we are dropping those _WRK, _SRC, directories entirely from OtterScript plans in favor of something a little easier to reason about. We'll have more information about this behavior in an article soon.

Thanks for letting us know; this is something we want to work very consistently in 5.0, so it's possible it's working half the "old" way (OtterScript plan wrapping an old action), and half the new way (a new "operation").

Thanks for the help... in the end I found I needed to install Microsoft Visual Studio 2012 Agents on the build server. The project was then able to build successfully.

First of all, Thanks for your answer. I know it, but the problem is that I have more than one deployable in an application, sometimes the new builds has no need to re-build all of them, but in the last step of my deploy plan, I need to update a sql table with the versions of all the deployables included into the build deployed. For that reason I need to access an specific deployable, and then, of course, I will use the $referencedBuildNumber function. "$ReferencedBuildNumber : Returns the build number referenced by the imported deployable in the current scope." Thanks

The tutorial still needs to be updated (we will do this for v5), but take a look at the SDK Documentation for how the variable base classes work now; basically you declare them as properties and then use attributes to indicate that they are parameters.

Thanks, I was able to download the Oracle extension and modify it to look for a custom statement delimiter for testing purposes. A few tests seem to check out fine so I'm able to deploy package updates this way. This means I have to customize my deploy scripts but this may be an acceptable tradeoff for now. I've made my statement separator tokens comment sequences (i.e. "--$$") so that the script can still run in sql*plus.

If that action is causing issues with that, to get you running again just replace it with a command line action with the same arguments from the BuildMaster log, then add your reference paths that way. As for the actual question, I believe if you specify the same property twice, it concatenates them.

Not currently, it's just per application level right now. We will definitely consider adding that in a 5.x release!

Very cool, thanks for sharing! I actually ended up doing the same thing by making a curl call, but I like your way better. I'll try to give the plugin a try sometime.

This is a bug in the Release_PurgeReleaseData stored procedure that was fixed in a later version. You can patch it by editing it and removing these lines: /* 2c) Configuration */ DELETE [ChangeControls] WHERE [Application_Id] = @Application_Id AND [Release_Number] = @Release_Number NOTE: make sure it's the 2c) line and the 2 following you delete... the 2d) one is correct. (The delete from the ChangeControls table is in there twice for some reason, which is the cause of this bug.)

This is a pretty common deployment for BuildMaster; there are a lot of options, but the easiest thing we've seen is to do the "exploded WAR" strategy -- basically, unzip the war file into the catalina_home directory, and kick the tomcat service. This saves a lot on initial load time as well.

In short, don't use the wizard, we have decided to remove them in v5 anyway because of problems like this. Instead, simply create a Standard Application, and then visit the Workflows tab, and add a Build Step that imports from TFS. That's actually all the wizard is supposed to do anyway.

Take a look at the Getting a Simple Application into BuildMaster Tutorial for a good way to get started!

If you have locked yourself out of ProGet, then you can use ProGet.Service.exe to reset the Admin account.

There is no special path; a cached packages is stored under the feed's package store, alongside regular packages.

The easiest option is to put them directly in the URL of the repository: https://username:password@domain/