@ashah_4271 can you share your OtterScript? and show specifically what you'd like to do? Happy to help if we can!

There are 2 ways to handle this: set a higher-scoped variable to the default value, e.g. set $BuildTestsFlag to false at the application group or system level; this removes the need to check at all, or: use if !$IsVariableDefined(BuildTestsFlag) function to determine if it doesn't exist

Well, I've been meaning to upgrade anyway. If that's something that's available in v6 means that I'll be doing that sooner rather than later.

After some digging I determined that Mpa (%) types are not currently supported. I was able to get past this by embedding JSON in a scalar string, and then use %FromJson() to convert to a Map type in OtterScript.

Yes, here is the tracking issue: BM-3165

Hello Josh, I agree that this would be very useful to have. I've filed IEE-8, which will allow the use of variables in block descriptions if the script contains ##AH:EvaluateStatementDescriptions at the top.

Outstanding, thanks Alana

Hi Alana, Thanks for your reply. I ended up submitting a bug Ticket which I need to respond to. But in response to your comment, The Agent and the runtime user are both the same account. Aside from the simple script above, I also tried to get it to return the value, and it would only return 's' in once case, error in another , or indicate the value was part of a Dictionary, which I'm guessing is meaning its within an array. Tod Hoven is my contact for the issue that I will be working with, but at the moment my BuildMaster instance is offline, so I will be following-up once our environment is back online. I'll try and remember to update this thread with the fix once we have it... -Trent

Hello Megha, In PowerShell, to create a JSON object key with a dollar sign in it, you need to use this syntax: "`$KeyName" So your object would look like this: $CreatePackageParam= @{releaseNumber=$ReleaseNumber; applicationName=$ApplicationName; "`$SiteName"=$SiteName; } Otherwise, PowerShell replaces both instances of $SiteName with the value in that variable.

You are using it correctly; there is a bug in that particular endpoint that ignores the variables for non-legacy plans, see: Issue BM-3077

The problem here is that there is not exactly 1 environment in context. I'm guessing this is an orchestration plan? Configuration plans will already bring in the environment context if there is exactly one environment. The way this will be solved (targeted for v1.6, but may appear earlier in a v1.5.X maintenance release) is by the following rules: Context will solely be determined from environment associations of servers (this changes the current behavior which relies on orchestration jobs being targeted at an environment in order to bring the environment into context) Parent environments will only be considered for user permissions and variable resolution If there is not exactly 1 environment applicable to the current server in context, $EnvironmentName will result in an empty string (so the same as you're seeing now) We will add @EnvironmentNames which will resolve to a list of all environment names in context (including an optional parameter for including/ignoring parent environments)

That operation looks exactly like what I am trying to achieve. What is the behavior when all of the servers in the pool have been acquired? Does current execution wait or does an error get thrown?

Don't use that, use the Variables API instead.

Your best bet would be to simply wrap the deployment plan that gets called in a "if $RestartServer". I agree about visibility of skipping, but it's not supported at this time.

Just as a follow-up, we are going to clarify this behavior and "fix" it to be more like your use-case, see: http://inedo.com/support/questions/6290#inline-post-6291

We will implement this eventually once we have the specs nailed down. The plan is to offer a per-variable setting (in the same vein as the "sensitive" option) so it shouldn't break backwards compatibility.

Yes that is a bug then. I'll submit a bug report.

Release template values are currently only used by the user interface, as a means of assisting users enter key/value pairs (variables) for a release or package. They API does not reference these, but you can pass variables into the APi quite easily.

There is no built-in variable function to do that, but it could be done with a custom variable function that does a lookup for the configuration variable based on the environment. Like $EnvironmentVariable(envName) or something. Let me know if you run into troubles, I can probably help! I don't know how easy it would be for us to generalize a lookup function, because there are so many different types of configuration variables (env, server, app, etc), and one might be desired for SErver, Role, etc.