Config Transformation Ignore Error variable not working

Hi,

The upgrade to 3.0 changed the default config transformation error handling behavior, as you know. My problem is the deployment doesn’t pick up the Octopus.Action.Package.IgnoreConfigTransformationErrors variable, in all the permutations I’ve tried. I’ve checked the working folder on the deployment target, and the variable is in the list where I expect it, but the deployment still fails.

Below are some of the links I’ve gone through:



http://community.octopusdeploy.com/t/web-config-transformation-missing-key-is-a-error-instead-of-warning-resolved/417

Any troubleshooting I can run to get to the bottom of this?

Hi John

Thanks for getting in touch. I tried to reproduce your problem but it worked perfectly. I’ll walk you through the steps I took and hopefully you’ll be able to get it working.

  1. Created a simple web app w/ a single config transform (Web.Release.config) and deployed it w/ Octopus. (see images WebAppTransform01 and WebAppTransform02)
  2. Updated Web.Release.Config to add a second transform referencing a non-existant app setting. Deploy with Octopus and confirmed it failed. (see images WebAppTransform03 and WebAppTransform03)
  3. Updated the Octopus project variables to add Octopus.Action.Package.IgnoreConfigTransformationErrors w/ the value True. Then I created a new release and it worked fine. (see images WebAppTransform05 and WebAppTransform06)

NOTE: I used Octopus 3.0.11 thought it shouldn’t matter.

Sorry if you were notified that I closed this. I accidentally clicked ‘Comment and Close’ as I was uploading the images.

Hope this helps!

Rob

WebAppTransform03.png

Hi Rob,

Thanks for the response. I don’t know if it makes a difference, but the
particular error I get is

Unable to update the config file - it may not be a valid XML file: Root
element is missing.
This is the error from the last successful deployment in 2.6, it’s failing
in 3.0.6.2140.

Also, in checking the version number, I noticed it looks like my license
has incorrectly expired. Expiry date is 2015-12-10, so by any date
convention we should still be eligible for updates. Can you shed any light
on this?

John

Hi Rob,

I found this: https://github.com/OctopusDeploy/Issues/issues/1789
This addresses the problem with the license message. I’ll retry the
deployment with 3.0.12.2366 and come back with all the error codes.

Thanks,
John

Hi Rob,

I’ve attached the deployment log. You can see that the variable is being picked up at line 36, but it still fails on the XMLException at line 281.
I’m comparing this to a successful deployment on 2.6 where the equivalent umbraco.config line is

           |         Warning: Find and update variables in umbraco.config

Verbose | Scanning configuration file: D:\Octopus\Applications\Staging\umbraco\1.88\umbraco\app_data\umbraco.config
Warning | Unable to update the config file - it may not be a valid XML file: Root element is missing.

Thanks,
John

ServerTasks-1615.log.txt (24 KB)

Hi John,

Thanks for the reply and the additional details. First, I’m happy you found the Octopus license expiry issue has been fixed. Second, I think I’ve found the source of your deployment error. It appears that you’re using both Octopus Config transforms and Config variable replacement. The transforms feature completes successfully (ignoring any errors) but the variable replacement feature executes and it’s failing to open one of your config files as it’s not valid XML. I’m guessing there is a blank or binary config file in your NuGet package that is causing the issue. The config variables feature is convention based and it applies to all .config files. I’d suggest reviewing your config files and see if you can exclude/rename or handle it differently.

Hope this helps.

Rob

Ah, I understand.

I hope the warning/error handling isn’t a permanent breaking change for the
variable replacement. Is there a related variable for suppressing errors in
the replacement feature, or a way to exclude files from the search?

Thanks again,
John

Hi John,

Thanks for the reply. This is an important issue so I’ve created a GitHub issue to add a similar ignore variable for Config variable replacement. It should be fixed fairly soon as it’s marked as a priority. You can follow it’s progress here: https://github.com/OctopusDeploy/Issues/issues/1897

If you need a short term workaround, I’d rename the file in the package and then rename it again in a post deploy script.

Hope this helps.

Rob