Optional variable templates

[michaelnoonan]

Some of our customers have variable templates for tenanted projects where the value is optional, and can be ignored by default. However, there is no easy way to express this in Octopus 3.4.0. There is a workaround, where you can bind the default value to a global variable which is empty, but this isn't easily discoverable.

It would be nice if you could use a checkbox to mark a variable template as optional.

null or "" values are treated the same in Octopus, so you can't say "this variable template value is optional" using a default value of "".

Workaround

Set the Default Value of your variable template to #{if DummyVariable}never_true#{/if}.

This will "trick" the variable template validator making it think there is a value provided, in turn making the visual warning and deployment error go away. At deployment time the expression will result in an empty value, effectively making the variable template "optional".

Links

Source: http://help.octopusdeploy.com/discussions/questions/8994-optional-variables-in-project-variable-templates

Source: https://secure.helpscout.net/conversation/354210736?folderId=571731#thread-968370423

[aceptra]

"Optional".. yes. Consider an attribute for a tenant like "Address 2". Not every tenant would have that. This is the case with one of our deployments.

[crmckenzie]

Consider a variable like "url-prefix". I have some tenants who would deploy to "my-tenant.fredbob.com" but others would just use "fredbob.com"--thus the url-prefix is optional.

[Ermesx]

Optional also could mean required only for specific environment for instance I have variable which depends from tests environment were I put specific "target system version" because I have many test copies for different purpose but this concept doesn't exist for production environment there is only one correct version.

I would like to limit project variable to chosen environments scope.

[harmeetsra]

Hello There,

is this feature still under development or pipeline? is there any expected date for this one?

Thanks Harmeet

[michaelnoonan]

Hi! We don't have an expected date for this one, but we are committed to address it.

On 2 October 2017 at 23:14, harmeetsra [email protected] wrote:

Hello There,

is this feature still under development or pipeline? is there any expected date for this one?

Thanks Harmeet

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/OctopusDeploy/Issues/issues/2709#issuecomment-333530522, or mute the thread https://github.com/notifications/unsubscribe-auth/ABjVvnM0CZtg67MVkI1UpYhr5clXDmdoks5soOG4gaJpZM4J0sdz .

[michaelnoonan]

I would like to see this kind of thing happen too, but it hasn't come to the top of the "priority-vs-complexity" list. At this point it we think it will be implemented as a first-class citizen in remote release promotions: https://octopus.com/blog/remote-release-promotions-rfc

[sarbis]

My case is exactly what @crmckenzie wrote - url prefixes for certain tenants need to be empty strings. Added dummy variable substitution expression which always evals to false as a workaround for now: #{if DummyVariable}never_true#{/if}

[Peter-B-]

Is #{if DummyVariable}never_true#{/if} still the way to go? Even after nearly 5 years?

[Peter-B-]

How about creating a global variable #{Empty}?

[LindnerBrewery]

#{Empty} would be the option I would also prefer.

[BuriedStPatrick]

Very interested in an update on this. We have a ton of feature-toggle stuff where one variables is only required if another is set. Just having optional values would be 50% of the journey for us. For now, we've "solved" this by manually validating the variables using a script in the deployment process and setting optional stuff to empty strings. Needing to maintain this, however, isn't a great solution, and we won't know if something is wrongly configured until we run the deployment.

Additionally, having an #{Emtpy} property or setting an empty value just isn't a viable solution when you're also using things like Structured Variable Replacement in appsettings.json files for .NET projects. In my opinion, it should be done "properly" so a variable simply ceases to exist at deploy-time if it's optional and not set.

This is really becoming a core part of maintaining the infrastructure of a lot of our complicated projects. Presenting developers with a truckload of properties that may or may not be optional is quite detrimental to internal adoption since I have no ability to shield others from the complexity.

[ay-azara]

Tad unfortunate this isn't supported. Haven't used variable templates before so my solution was just to create a tenant tag, attach it to the tenants I needed different values on and scoped the value of a global variables to tenants with that tag.