Step Template parameters priority

Much has been said about Step Template parameters priority and conflicts with Project variables.
You say it’s know behavior (not an issue), but don’t you want to reconsider?
I see it much more logical to have higher priority for Step Template parameters and I can’t see the downside here, which I cannot say about the current state.

Hi Peter,

Thanks for getting in touch!

Most of the discussion on this subject has been for scenarios where parameters in step templates are accidentally named the same as a variable within a project. We added a warning message to make this more obvious to allow users to identify and resolve the issue.

Modifying the actual behaviour of this entirely so that step templates take priority isn’t something that we would consider for two reasons.

The first being that in our view, anything configured within the project is more focused and relevant.
The step template is at a higher level than a project, and therefore is more likely to have a more general/blanket parameter value (this also applies to other similar items such as library variable sets). As it isn’t possible to conceptualise every possible application of the step template at time of creation.
Whereas the project variable is very specific to that project, and in the vast majority of cases will be more applicable than the step template parameter.

The way we see this playing out is as follows:

  • A user creates their step templates, library variable sets and other generic items
  • These are applied to all relevant projects
  • A new project is then added where the value provided by the generic step template(or library variable set etc) doesn’t work
  • A project variable is then created within this new project to override the default value.

If the step template parameter had the higher priority in this scenario, then it wouldn’t be possible to apply this template to all of these projects. You would have to create a new template specifically for the new project, with a parameter configured specifically for that project. This would contradict the concept of a template.

The second reason that this is unlikely to change is that all of our users have created their deployment pipelines with the current model in mind. A change to this would break all of these projects and require users to make changes to all of their pipelines.

I hope this helps provide some clarity as to why this works the way it does.

Best regards,
Paul

Hi Paul,

Thanks for response.

Some points from the other side:

Use of community step templates is risky and sometimes impossible without lot of extra work.

I consider step template parameters as direct interface with step template instance functionality. How could be project variable more specific?

If someone wants to create step template - variable set ecosystem, is it not better to use step template parameters with default values using variables, that are defined in variable set? You can always override that variable within project or even change value for single step template instance.

This change could only break, from my point of view, very shady configurations.

Regards,
Peter

Hi Peter,

Would you be able to expand some more on how the current method is causing problems for your configuration?

Hi Paul,

I only use Step template parameters and never direct access to Project variables or Variable sets from Step templates.
So every new variable in Project or Variable set is potential conflict with bad consequences.

I have renamed lot of Step template parameters (lot of work).
Then I realized I cannot do this for Community templates, so I have to duplicate and maintain them or rework my whole variable system with every new Community template with catchy name parameter.

I really like using Octopus and I think this aspect is worth a fight :slight_smile:

Hi Peter,

Thanks for sharing some more about your use case. I’ll pass this along to our product team, but as this would be a major change and would impact other uses significantly, I’m not sure it will be accepted.

One suggestion that we offer our users to avoid situations like this where variable names can get duplicated or become confusing is to add a prefix to them to denote where they are defined.
e.g.
Project.Password
VariableSet.Password
Template.Password

Regards,
Paul

Thanks Paul,

One possible non-breaking solution would be adding another way of accessing Step template parameters and Step template parameters only.

Regards,
Peter

1 Like

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.