You could just bypass it on the promote page, by selecting "Do Not Execute" and then override the promotion status to Successful. That might be sufficient? Otherwise, we don't have a good way to evaluate whether or not a pipeline stage should advance. Perhaps one idea would to use a variable for targeting? or maybe a (JSON-only) option that says "skipStep" or something that you could have a $Variable as. Just ideas, not sure if they're feasible!

It would appear this isn't currently supported, you're right; we will add this in a future release!

Great idea; I've resolved this in [BM-2314] , and it will ship in next release of BuildMaster. Now it displays "AppName::DeployableName"

This appears to be a bug - it should work exactly as you have stated. Our internal issue ID for this is BM-2281 and should be released in the next maintenance (or minor) version (whichever comes first).

The way is correct, but it appears there's a bug in the evaluation while accessing the variable; this will be fixed in [BM-2278], which brought code in from Otter that fixes this bug.

Thank you. The source code makes it explicitly clear what is going on. I was assuming that the OtterScript variables were being parsed out directly from the text input rather than being passed to the PSParser before hand. This also explains my troubles with the List and Map variable types as I was attempting to utilize them inline in my PSExec steps. I would suggest mentioning this parse behavior in the PSExec documentation link text and in the "Inline Script Execution" section of link text

This is handled by Release Package Variables within a Release Templates. They work basically the same, except now you can create multiple sets of required variables, depending on the template chosen at release time.

In v5.4, we will have a "Custom Setter" for template variables which would allow for this scenario. Our primary use case is to allow for a searchable list of packages from ProGet, or builds from teamCity/Jenkins/etc to be populated.

Just a heads up, that we've updated the docs with our proposed specifications, always open to feedback! Formal Grammar Formal Specification Strings and Literals We don't have an ETA; the changes aren't really that difficult, but once we implement them we're stuck with them.

It's supported using the Legacy Action, which isn't ideal obviously. This will be replaced with a function in v5/OtterScript: # reads at most 250 characters from the file set $hdarfs = $FileContents(c:\hdarfs\info.txt, 250); Log-Information $hdarfs; However, this function is only available in 5.3 (which is shipping this week).

Hello, I was not able to reproduce this. Here is what I did. Create a new PowerShell Asset... Name: Test Script Parameters: none One ambient variable: MyEnvVar ==> $EnvVar Contents : Write-Host My var is $MyEnvVar; Create a variable on MYSERVER: $EnvVar = my server var Create a new application with a deployment plan that has a single action (targeting MYSERVER) that calls Test Script Output is My var is my server var, as expected I also deleted $EnvVar from the server, and then created it on an environment the server is associated with, and it works as expected. When I deleted $EnvVar from the environments, it produced the literal output (My var is $MyEnvVar) upon running. So, my guess is there's a typo somewhere... best, Alana

Unfortunately we're not able to diagnose this with the information you provided. That error really doesn't make sense in the place it's happening. Can you please submit a ticket with: Configuration Variables defined at various levels (System, etc) Plan as OtterScript Pipeline as JSON Full Execution log, including the full stack trace you sent

The easiest workaround is to declare the variable at the top of your plan. set @WebServerFeatures = @(...) Otherwise we will get this shipped by end of day!

Thanks. That would be great to, app to app, I am referring to within an app itself. But it sounds like both would be the same so that would be perfect. Looking forward to 5.

Tod, Thanks very much for this piece of info and the source. Very useful. I've been able to do complete my extension, working all good!

Yes, that's the directory used by the "local agent", for the buildmaster server.

In the v4 execution engine, your best bet is to create a file with that name, and then read the file contents into a variable. In the v5 engine, you will be able to export variables via powershell a little easier (example: PowerShell & Scripting from Otter docs.

Yes, in the new/v5 execution engine, we wrote a variable function called $EnvironmentVariable(name) that returns the machine environment variable. The current/v4 execution engine does not provide agent/server context in a variable function, so there's no way to write a variable function that executes on a remote machine.

The current (v4) execution engine does not support Array-type variables, so this would not be possible using that technique. But we will soon (couple weeks) be shipping v4.9, which will include a brand new execution engine, that will include Array/Vector variables, so you could do something like ... foreach $value in @MyVariableList { Transform-Config (...); }

Yes, that's correct; if your doing this with a custom extension, then you can use the "StoredProcs.Variables_CreateOrUpdateVariableDefinition" method directly, and pass null in where appropriate.