Configuration Variables Feature - 'treat error as warning'

The ‘Configuration Variables’ feature is great - it let’s us replace variables in whatever .config files we find without having to use the #{…} syntax. I do, however, have an issue with this feature which is preventing us from deploying one particular project.

We’ve got a few .config files in our deployed package which don’t conform to any sort of sane XML standards. Consequently when the feature runs, the XML file cannot be read, causing an exception to be thrown, which causes the whole deployment to fail in a mass of angry red text. The culprit is ConfigurationVariablesReplacer.cs line 26, in calamari, I think.

I notice there’s a nice option on your replacer class to treat such exceptions as warnings instead - but I can’t find anywhere to set this in the UI (it defaults to ‘false’, meaning all XML parse errors are treated as deployment errors).

Am I missing something obvious in the front-end, or could this be added as a parameter to the Configuration Variables feature?
… or alternatively could some file pattern constraints be added (as in the ‘Substitute Variables’ feature)?

What are my options for working around this in the short term?
Unfortunately I can’t make the .config file behave as it’s a third party component.

I’m running OctopusDeploy 3.15.7, with the latest calamari on my tentacles.

Thanks!

Hi Dan,

Thanks for getting in touch! Checkout Octopus.Action.Package.TreatConfigTransformationWarningsAsErrors and Octopus.Action.Package.IgnoreConfigTransformationErrors as document here (and more info.

Setting the first one to false will get you the behaviour you mention, but perhaps setting the second one to true may be better. You will need to add these as project or library variables.

Hope that helps!

Robert W

Thanks for your prompt response :slight_smile:
I’ve tried both of the above, however I get the same result (I recreated the release to ensure the new variables were used). Please see the attached screenshot.

It looks to me as if these variables are for the Config Transform feature, rather than the Configuration Variables feature?

Thanks!

Oh, I’ve sorted it - the actual variable I needed to set was Octopus.Action.Package.IgnoreVariableReplacementErrors.

Thanks for pointing me in the right direction, though :slight_smile: