Hi, I need to use the Configuration Variables build feature (If set, replace appSettings and connectionString entries in any .config files)
However, I am packaging and deploying to Elastic Beanstalk, as such I have a .ebextensions folder off the root containing a “eb_initialise.config” file. The ‘problem’ here being that this file actually contains yaml markup and not XML, so when this feature runs, my build fails:
System.Xml.XmlException: Data at the root level is invalid. Line 1, position 1.
I understand what’s happening; it’s trying to parse yml as XML which is never going to be successful, however on the actual “Configuration Variables” itself, the only option is
[ ] Replace entries in .config files Tentacle will look inside your .config files and attempt to replace any …
For me, this is a bit too indiscriminate. At least when you use the “Configuration Transforms” and “Substitute variables in files” options you can go along with the default or supply your own pattern. However with Configuration Variables you’re in or you’re out.
To get around this I’m going to have to check into source control as “eb_initialise.yml” then create a step in the Beanstalk Deploy that renames it to “eb_initialise.config” before it packages and deploys.
Is there a better way or you please add a feature request to improve this step?
I’m sorry to hear you are experiencing this issue, I understand this behavior can be frustrating.
In this instance, I would encourage you to leave a User Voice request for this as we consider these requests when planning our roadmap based on community support. I can definetly understand how applying a filter here would be of assistance in this area.
As far as a workaround is concerned, I imagine you could either;
Using the Custom Deployment Scripts feature, use the Pre-Deploy script (This script will run after the package is extracted, but before any configuration changes are made.) to rename the file and subsequently have the Post-Deploy script (This script will run after IIS or Windows Service changes are made.) change it back.
or
You could enable the Don’t show transformation errors variable. This can be done by creating the Project variable Octopus.Action.Package.IgnoreConfigTransformationErrors and setting the value to be True. The problem with this, however, is that you would need to check to ensure that your transformations are being run correctly.
I’ve included a link to our documentation regarding Suppressing Configuration Transformation Errors below;
If I’ve misunderstood your query in any way, or if you require further assistance or clarification, please let me know
