@jimbobmcgee said in Apply-Template adding unexpected CR newline chars: Without wanting to hold you to a particular date, what is the typical release timeframe? We're targeting BuildMaster 2023 for Q3/Q4 and Otter for Q4. We don't have any dates beyond that at this point. And it sounds like you understand quite well why we're not so keen to jump on making relatively easy changes - definitely a lot to consider. We have a lot of "product debt" like this and have learned to be a lot more cautious. That said, I think as long as it's documented it's probably okay. That's the hard part of course (writing docs) - but there's a Note attributes that can be added to explain things as well. cheers!

Are you saying you can't create a job from a template? The main purpose of the template is: Instead of specifying the plan and server targeting each time you create a job, you can create a job template that will specify these for you. The template can also specify variables that will need to be entered when the job is run. While this can save you a few steps when running jobs, the biggest benefit of job templates is that, once defined, you can now trigger jobs using a the job trigger API. This will allow you to use nearly any other tool, such as Jenkins or a PowerShell script, to trigger an Otter orchestration job. However, we plan to expand it to be a lot more useful with better variable selection, etc.

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.

You can do this with default values. template Check_Version<$App, $Role=default> { } And then test if it's the default value to see if it wasn't passed in

Hello; I've added a feature request for this. There is no ability to do a "mass edit" like this I'm afraid.

This was introduced into 5.8; so please update to the latest v5. https://inedo.com/buildmaster/5.8

Hey Tod, Thanks for the answer and apologies for not getting back to you sooner... I see a new version of Otter is now available with the fixes included, so I'll try that out and see what happens. Thanks for the great support! Andrew

Hello Jamie, There's not a way to do this through the BuildMaster interface, but if you have access to the SQL database, you can run this: SELECT P.[Plan_Name], A.[Application_Name] FROM [Plans] P LEFT JOIN [Applications] A ON P.[Application_Id] = A.[Application_Id] WHERE CONVERT(VARCHAR(MAX), P.[Plan_Bytes]) LIKE '%call MyPlanTemplateName%' There's a possibility of false positives because the SQL query doesn't actually parse the plans, but it should be able to give you a rough idea of where a template has been used.

I like the idea, but of course there's definitely some questions and things we'd need to think about before we can spec out the feature. Just some initial thoughts... Should this really apply to all applications, seems only a few might want to share one Pipelines and deployables are not global (well, you can have a global pipeline); what to do about that? Should UI restrict from choosing? Who can edit these? Admins only? How else will they behave differently? And then of course, there's the question of how this will tie into the (unspecc'd) "Projects" concept (cross-application releases)

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 }

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)

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).

The environment on a raft affects who can access it, but not which raft is accessed. Asset names with no RaftName::part always use the Default raft. There's a bug in the implementation of OtterScript in the current version of Otter that makes it unable to call templates from a non-Default raft. Running a plan from a non-Default raft is also slightly broken in that it brings up the wrong preselected plan, but selecting the correct plan afterwards works.

We had considered this as an option when designing templates, but decided against it because of the additional complexity required. The main challenge being, a user with Releases_Manage can already change the pipeline (or any other attribute) on an existing release. Making a "restrictive" template be a securable feature would require new permission attributes (and thus be more confusing/frustrating to use), and making it a convenience feature would give it the appearance of security (which is also bad).

This does involve a bit of refactoring... but we should be able to get this into 5.6, shipping on the 18th.

That's generally the idea of the arguments: those are the required variables. template MyTemplate<$var1,$var2,$var3> { ... } It's generally a good practice to use these instead of external or configuration variables. But you can always use the $IsVariableDefined function as well. if !$IsVariableDefined(my_var_name) { error; }

You are not going wrong :) Support for XSL as the template and data as the instance will be added in v5.3.4 as a separate template type so it doesn't break existing deployments. We'll release this within the next day or so.

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!

See the Configuration File documentation for more information.