Hi David, It appears that only the start of a statement block shows in the execution log.. # Visible in execution log # This is not bisible in execution log { } # Visible in execution log # This is not visible in execution log { # This is not visible in execution log } # not showing in execution log Let me know if you have any specific examples that aren't working as expected. Here is the full documentation for OtterScript comments https://inedo.com/support/documentation/executionengine/otterscript/comments-and-descriptions Thanks, Jason

Hi Jim, Apologies for the lack of response here, but I wanted to let you know that we had quite a bit of back-and-forth internally on this post and implemented nearly all of your expectations: you are absolutely correct about the variable context not behaving as expected, and the biggest problem was that the behavior of certain variables (particularly $RoleName) was undefined we've updated the docs to reflect the "new" behavior in the latest version (v2.1.0 at the time of this post): https://inedo.com/support/documentation/otter/core-concepts/jobs#orchestration-job-context we release v2.1.0 last night with these changes included Thank you again for the detailed report and reproduction steps.

I've come across this too... but I'm pretty certain it's not going to possible. In the visual editor, all properties all text boxes that are blank by default (which means, not specified), and any characters in those boxes are always escaped ("" would become "\"\""). I made a variable function called $Empty that just returns "". Maybe I'll submit as a pull request to InedoCore...

One common way to do this in BuildMaster v4 is to use two pipelines; a "blue" and a "green" pipeline. Another thing is to have a "Blue" and a "Green" environment, and then a pipeline like: Int > Test > Blue > Green Then, basically skip Blue or Green depending on the workflow. You can also have operation groups / action groups with predicates like "if $BlueGreen = Blue". You can certainly use the Set-Release operation (or ACtion in v4) to set configuration variables on a release.

I certainly see the issue. Where this starts to get tricky from a UX perspective is that some folks have long stage, server, and plan names. So, we need a way to better represent this data in a compact view.

Your template can look like this: template MakePair<$First, $Second, out @Pair> { set @Pair = @($First, $Second); } And the plan that uses the template can look like this: set @Fruits = @(); call MakePair { First: Apple, Second: Orange, Pair => @Fruits }

Thanks, I believe this was caused by the anti-virus program. Once I excluded the folder from the scan, the problem went away.

Hi Ben-- This is a fantastic solution, and suits the situation perfectly. Thank you!

Configuration file versions and database change scripts must be tied to a specific release number, so we create 0.0.0 to associate those. It might be best just to purge that release if you don't really use it.

It's cool, I switched to global template to be called. It works fine. Thanks!

Well, so that's basicaly the idea of a deployable; you could have a web deployable and a database deployable. Of course, the same pipeline is used, but you use a for deployable xyz block to determine whether particular things execute. You could use this, in combination with pipeline targeting, to accomplish this. They would still follow same linear pipeline path, but some stages would only deploy one or the other. Otherwise, you can use multiple applications, and then the create- and deploy-package operations. Down the line, we will have multi-release projects that allow you to tie together multiple releases of multiple applications.

Hi Jason, there's not currently... but I've added a request to get this in a maintence release under BM-2374 @ConfigurationFiles([AppName]) @ConfigurationFileInstances(configurationFileName, [AppName])

Yes of course, smacking forehead now! Thanks!

Unfortunately i'm not familiar enough with CakePHP to advise on how to stop the service non-interactively. I would perhaps suggest to modify the batch file to not look for an exit code? BuildMaster will basically just run whatever process you ask to, so the batch file is what's waiting...

I'm migrating all our "workflows 4.9.7" to pipelines 5... then converting our legacy plans to the new plans...maybe in the future will not so often than now...but actually I have that situation almost every time, and sometimes the errors appears after 10 or 20 minutes of an execution...

This is only available as a legacy action as of 5.2.1; there is no corresponding Operation built for it yet, but we will get one going soon.

The "Generate Release Notes Action" in those release notes was referring to the same action as 4.9.7, which was not implemented in 5.0.0. The Generate Release Notes Operation for v5 plans is available as of v5.2.3.

Aha! That's the ticket -- setting ErrorOutputLogLevel to "Warning" is just what I was looking for. For some reason I had thought the option would do the inverse (e.g. elevate warnings to errors). Thanks a ton for the help, -J

That certainly does sound like a bug. We'll make sure to look into that. The syntax for calling a template in text mode is: call MyTemplate ( arg1: value, arg2: value ); So it's basically just like an Operation except for the keyword "call" in front. That is supposed to be documented here, but it looks like we don't have that listed yet. We'll also make sure to get that added to the docs before we're out of beta. Thanks!

In BuildMaster v5, a global plan is intenteded for use in a pipeline stage/target. Use a global template (Plans > Templates), which can then be called as if it were an operation.