In the v5 plans (which we will ship in 4.9), you can have "output variables" from your powershell scripts. But currently, you can't communicate back to the BuildMAster execution engine via a script with anything but exit codes.

Hi Simon, The variable matching isn't taking place because you're using the simple syntax (see "notation" under Variables Documentation). Specifically, BuildMaster is looking for a varaible named "DeployableName_", which doesn't exist, and thus it is replaced as a literal. So, either change to "$DeployableName-$BuildNumber" or "${DeployableName}_${BuildNumber}". Alana

Apparently only the PowerShell scripts support variables in parameters and in scripts at this time, so we will have to add this feature for shell scripts as well. Ideally it will be included with the initial 4.7 release, but may be a maintenance release behind that. For now, if you use the Execute Shell Script action and enter the script as text or a file, it should work as you expect.

Off the top of my head, that seems like the best/easiest way. I think what we need to add is the ability to mark a manual action "incomplete" instead of forcing the user to cancel the deployment... that should make it easy then to create a Predicate that checks whether all manual actions were marked complete. I'll add these as feature requests for the time being, but am not sure when they will be shipped since your scenario should work fine for now.

FYI- 4.6.4 has been released, and this fix was included.

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

Using a \ character is correct for escaping in JSON; that should work. We will try to reproduce this, but in the meantime are you able to use single quotes instead in the XML? Assembly='BuildMasterExtensions' should also parse as valid XML if I'm not mistaken.

The built-in action only supports setting the value for a known variable, but you could either write a custom action/extension or add 3 actions that set: key=(value) => $Value (key)=value => $Key Then add a Set Variable Value action that sets $Key = $Value

This behavior is supported, yes; however, starting/stopping services requires Admin privileges. Does the user hosting the BuildMaster service have this?

When run in parallel, there is no guarantee with the ordering the value is set (and the change would be observed in different groups), so you'd have to create separate variables in each group if you have multiple action groups using different server groups.

This is a known issue (BM-1546) for BuildMaster v4.3.8 and will be resolved in v4.3.9.

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

Thanks Peijen! In this case, you would use the Set Variable Values action to set the TargetDatabaseUsername variable name to %DatabaseUsername%. When the action is run, the TargetDatabaseUsername variable will be set to whatever the value of DatabaseUsername is at the time.

The root cause of this is that an undeclared execution variable is being created to override a declared non-execution variable. For example, if you create TESTVAR as a Release Variable but not as an Execution Variable, then use Set Variable Value to override TESTVAR value for the execution, it will exhibit this behavior. This will be fixed in a future version 3.7.1; either with a more helpful error or supporting the behavior.

Yes it would, but the editor UI may attempt to validate the credential. The way to get around this would be to edit the Action XML directly and replace the principal name with %VARNAME%. We'll add a fix in a future version of BuildMaster (likely 4.x) to bypass this validation if %[A-Z]% or something is matched.

What error message are you seeing?

Short of using the API, I can't think of a way to have the deployables be automatically removed based on variables. You could try a trigger, but that might not hit in time since those are on a few-second delay. The custom predicate sounds like it would work well.

Unlike most BuildMaster custom editors, the VariableSetters do not have a Context object; we'll consider adding this in future SDK versions. In the meantime, you'll have to "hack" it by looking at the HttpContext.Current.Request.Querystring for the release number, or perhaps locating the Release Number control on the page.

At the moment, build and promotion-level variables cannot be modified by an action during an execution. This is mainly because of the way default values are cascaded and inherited. We've talked about adding another variable scope (execution) that then is created and persisted only at execution time, which would then allow for this - but at the moment build/promotion variables are immutable once the build is created. You should still however be able to add variables during execution time - they just won't appear in the build summary. In a quick test I ran setting a variable that wasn't specified as a build variable worked later on in the execution with the code you have written, so I couldn't repro part 2. Make sure both the BuildMaster service and web app are restarted whenever the extension changes, otherwise changes might not actually be loaded by the extension loader.