The problem is that OtterScript attempts to parse those variables first. Just use quotes: set $foo = true; set $bar = true; set $foobar = $PSEval("$foo -and $bar"); Log-Information `$foobar = $foobar; # prints: $foobar = True

Just as a quick update, this was added to our roadmap as an item we will be including. It'll be implemented likely using the same mechanisms as the Repository Monitors, so it gives a lot more flexibility with regards to what it can do (create builds, create releases, etc), and also uses cron-syntax for scheduling so you have even more flexibility. No ETA, but I've added this post to the project plan so that we will upate it once it gets started.

Thanks for the usecase - that's interesting and a good point in favor of doing this. Unfortunately after a brief review I've found that it's a little more technically complex than we first anticipated. I still think that we will do it, but it isn't something we can just drop in the next release.

Hi Josh, Sorry, this seems to be a v6 glitch! But we're on it :) I've submitted BM-3192 and then inedo-docs/#6 to update our documentation. Your understanding of how the feature is supposed to work is correct, and your use-case is how it's supposed to be. Thanks for reporting it !

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.

This has been added as BM-3004, and is currently scheduled for 5.6.10.

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.

We'll add this, likely as a separate endpoint i.e. api/releases/create-from-template or something like that. It will appear as BM-2384 in the release notes (likely before it is actually documented on inedo.com).

That is exactly what I was looking for. Thank you.

Thanks for the clarification; I was able to repro this and logged a bug report (BM-2371). It will be addressed in a future maintence release.

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.

Thanks. That was the problem. After updating the Windows extension from 5.5.0 to 5.6.0 the powershell command is working again.

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

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;

Alright, v5.1.2 was released and it should be correct now :)