Fuzzy Variable Matching

Advice
1

Hello

I have a library set that is used to add in our id server url into a json file, which can change by environment.

The Json structure looks like this:

MyService:OAuthSettings:Endpoints:Url => http://someurl.com

We have multiple applications that in the same environment use the same Id server to authenticate. So traditionally, we would create a variable entry for each application:

MyService2:OAuthSettings:Endpoints:Url => http://someurl.com
MyService3:OAuthSettings:Endpoints:Url => http://someurl.com etc

This is ok, but I was wondering if the name of variable could be fuzzy, so it only has to be set up once? Something like this:

%fuzzymatch%:OAuthSettings:Endpoints:Url => http://someurl.com

So all json files would get replaced where the structure matched.

Thanks
Tom

3

Hi @tom.west

Thanks for getting in touch, and for your question - it’s a really interesting one!

From what I know fuzzy matching is not supported in the Structured Configuration Variables feature (it was previously called JSON Configuration Variables, but was renamed in 2020.4 when we added support for YAML and XML).

I did wonder if using variable replacement e.g. having something like this in your variable set might work:

Variable Name Value
#{Project.Service.Name}:OAuthSettings:Endpoints:Url http://someurl.com

Then in your projects have a variable which referenced the service name:

Variable Name Value
#{Project.Service.Name} MyService

When I tested it though, it didn’t work for me.

I’ve enquired internally to see if there are any other alternatives.

Best regards,
Mark

4

Hi @tom.west

I wanted to follow-up on this with another alternative to individual service variables. It would be to make use of the Substitute variables in templates - Octopus Deploy feature.

With this, you place your variable placeholders in your files, and then turn this feature on, and provide the path to the files you want values to be replaced with the variable value.

One downside to having placeholders in your json files is that your app might not be able to work correctly when running locally during development. Depending on your tech stack, you can configure some frameworks (.NET core for example) to load environment specific json files so that you can switch out the files used depending on which environment you are running your application in.

I’ll pass on the feedback to our product team about fuzzy matching / wildcard support, as I think it would be a handy addition.

Best regards,
Mark

5

Hi Mark,

Thank you for you feedback. You have correctly hit the nail on the head. When we used to use the web.configs and release configs, we were able to use the octopus variables in the checked in code. We switched to a bespoke json config as it was simpler to implement and the config was consistent across applications, but does give the draw back that to run the application as checked in, we can’t use the octopus replacements.

Hopefully the feature will be considered for a future release of Octopus. We are trying to keep our variables sets as small as possible so this would be very helpful.

Thanks
Tom

6

Hi Tom,

Thanks for getting back to me. That’s useful feedback for our product team to help understand the use case better.

When I hear back from them, I’ll update you here :+1:

Cheers,
Mark

7

Hi Tom,

I heard back from our product team.

They can see the appeal for this. The areas for consideration with this request is making sure that any change to the feature is backward compatible (so the : notation currently used still works), and also highlighting that the current way of working where the variable name is used as a selector means that you can end up with very verbose variable names (particularly when using it with XML XPath).

They’ve asked if you’d be able to create a user voice request for the feature enhancement.

Thanks,
Mark