Deployment error with .config file which is not xml (e.g. JS)

[ethar]

Hi

There appears to be a rehash of an old bug.

We have been deploying a project for a couple of years. It runs through a variable substitution for web.config and it has been fine all that time.

This month though, we’ve been hitting this error.

System.Xml.XmlException: Data at the root level is invalid. Line 1, position 1.

Looking at the logs, this is because it is trying to convert jshint.config in the assets of a generally available JS library (DataTables). Nothing appears to have changed in the packaging process and this file has been available for years.

It’s not entirely clear why this has suddenly started failing when it was OK before. A tentacle upgrade was performed before this release went live. A second tentacle upgrade has since been performed and it’s still failing.

I note that this was a problem with Octopus 5 years ago with Octopus on-site (at the time people were asking for the ability to exclude files from variable substitution). Could be a red herring:

Deployment error when having .config file which is not valid xml

Hi! I’m having error when deploying nuget package of my web application. Error message i’m getting is the following: System.Xml.XmlException: Data at the root level is invalid. Line 1, position 1. I have found that error goes away when i exclude quartz.config file from root folder of the application. And the thing is that quartz.config is non-xml file and it is used for third-party library Quartz, which i can’t just change to xml. So is there any option to tell Octopus to exclude certain .c…

However, this appeared to be closed (Add Octopus Server variable to ignore configuration variable replacement errors · Issue #1897 · OctopusDeploy/Issues · GitHub) and of course, it has been fine up until the beginning of this month.

Anyone got any ideas? Setting variables to globally ignore warnings/errors isn’t ideal.

[donny.bell]

Hi Ethar,

Thank you for contacting Octopus Support. I’m sorry you are running into this issue.

With your permission, I would be happy to log into your instance and have a look. Otherwise, if you would rather send me a copy of the raw task log and a sample of your jshint.config file, you can do that via Octopus.com -> Sign-In -> Support tab? Let me know once you do that and I’ll have a look.

I am going to try to reproduce this issue in a test environment. This sounds like a bug, but we want to be sure before getting our engineering team involved.

I look forward to hearing back from you.

Regards,
Donny

[ethar]

Hey Donny,

Sure. You can access the instance for this one.

For now, I’ve got around it by forcing JSHint off the build (we don’t need it at that stage in the pipeline as it belongs to a JS library). So you may need a copy of the JSHint file anyway. Drop me a message if you want to discuss anything further.

[donny.bell]

Hi @ethar,

Thank you for getting back to me. If you wouldn’t mind providing a copy of the JSHint file, that would be appreciated.

Let me know if you have any issues uploading.

Regards,
Donny