Have found the variable substitution help mentioning the filters like HtmlEscape and such here. Is there an option to define your own filters for that as well, or to have a RegularExpression filter?
The problem is that we have one variable that contains a full SQL connection string. From this variable we want to extract the database name (Initial Catalog=DBName;) which we then want to use as a derived variable. Ofcourse you could create multiple variables with servername, databasename, login, password for each environment and then derive the connectionstring, but that is very unwieldy with many deployment targets since you would have to manage four times as many variables. So does octopus have a way in which to define a derived variable which filters out part of another variable? Or to define our own custom filters which do that trick?
So something like this (assuming there are about 50 unique connection strings (and we dont want to manage 50x4).
Name Value
CNN Data Source=svr1234;Initial Catalog=DBWLC4;Integrated Security=False;User ID=loginname;Password=testing4pw
CNN Data Source=svr246;Initial Catalog=DBLL8;Integrated Security=False;User ID=username;Password=test123
CNN Data Source=svr246;Initial Catalog=DB788;Integrated Security=True DB #{CNN | Catalog}–> this should then resolve to DBWLC4, DBLL8 or DB788 etc.
VERSION #{DB}#{Octopus.Action.Package.NuGetPackageVersion}
hope this illustrates what we are after. In this case Catalog filter would extract the initial catalog from a database connection string.
Thanks for getting in touch. We don’t have anything like that unfortunately. My suggestion of how to do this is add a “Run a script” step before you need to use your connection string, then in that script parse the connection string as required in PowerShell and write the result to Octopus Output Variables (http://docs.octopusdeploy.com/display/OD/Output+variables).
For example you could have step called Extract ConnectionString with a script like:
Thanks for this brilliant answer! We will try it out today and let you know how it went. It might just be the type of solution which we can also use in some of our other config scripting challenges.
Hi Mark, I just realised that I did not give you final feedback which I promised. Your example did indeed solve our problem, though it took a while for me to realise that I had to enable “Substitute variables in files” in the deployment step to be able to replace the following (non-app-settings). Still bit surprised that I needed to include the octopus deploy step name in order to get the result, but now it works.
<httpProtocol>
<!-- These headers are dynamically updated during Octopus deployment to target environment -->
<customHeaders>
<add name="WingmanDatabase" value="#{Octopus.Action[DatabaseName].Output.DatabaseName}" />
<add name="WingmanClient" value="#{ClientVersion}" />
</customHeaders>
</httpProtocol>
Thanks again for the great support you are offering at Octopus!