Yes indeed, take a look at Asynchronous Blocks. Here is how you would do it in OtterScript: foreach $value in @list { with async { ... items ... } } await;

You could use a different workflow (or in v5, "pipelines" as they will be called)... and then have a different build importer/feed on each. Alternatively, you could not use the build importer, and just have a build step download the package and incorporate it as an artifact.

This would be very easy to do with a PowerShell script, so as an immediate solution, I'd suggest to do that. It'd also be very easy to patch/modify that particular action (CreateIisAppPoolAction.cs) That being said, this all applies to the "v4 execution engine", which will very soon be replaced with an indescribably better execution engine (the one that Otter currently uses). When we migrate the "v4 App Pool Action" to the "v5 App Pool Operation", it will basically look like the Ensure-AppPool Operation. So, as you continue to explore BuildMaster, do keep this in mind :) If you're doing server/infrastructure configuration (which, creating applications is definitely a part of), I'd strongly recommend looking at Otter as well!

Alex, different Workflows, of course! Sorry I should have thought of that. Thanks!

As written now, that promotion requirement is a very simple text-based match - anything more complicated would require a custom predicate.

We've published the BuildMasterBeta extension v4.5 which contains a fix for this. You can install this extension from the Admin->Manage Extensions page. This fix will also be included in the next maintenance release of BuildMaster, which will be 4.6.3. Thanks for the bug report!

Hey Alana, That option sounds fine to me. I certainly think it would cut down the time to spawn up new Applications for us.

For the time being, you've done it correctly! We may modify the build importer to support importing multiple at some point though since this is a fairly typical use case.

This question is answered here: http://stackoverflow.com/questions/26592119/buildmaster-net-framework

We've fixed the delete issue for the next maintenance release (v4.4.5), and we'll look into adding something to show the applications that consume the workflow - not sure if that will make that version or not.

OK they are now triggering. Thanks. Please can you advise on how to manage the release numbers For the regression test I entered a release number one higher than the current release on the standard. In reality my regression release will never go into production. The regression Test workflow is set to a loose Automatic Release Close-Out and disabled Release Cancellation. But the standard workflow is set to strict on all these. When the standard workflow is released into production, will it cancel my regression release. Should I set the regression release to a much high number or will this screw up the standard release numbering?

I think I'm getting a handle on this now. Pretty cool stuff. Thanks so much for your help!

This feature was actually added in v4.0, just change the workflow properties to allow deployments to any environment.

It was very helpful.

My fault, I had forgotten about the shared TMP directory and was focused on the WRK and SRC ones. It appears then that building the same app but different workflows at the same time is not currently supported, but there are workarounds. As an example, you could use a different environment (e.g. Integration2) for the patch workflow, then link/share all the action groups from Integration. If you were to then install a BuildMaster agent on the BuildMaster server (and add it via the Servers page), that agent would have its own set of temporary directories. All you'd have to do is update the "default server" setting for each action group in Integration2 to point to the agent server.