Running Octopus Server V2020.1.12
I am using Configuration Transforms for an ASP.NET website deployment. For this I am running the default XML transforms + 1 additional transform: ‘Web.Release.sitemap => Web.sitemap’
When deploying a release using this setup it breaks with exit code 1.
The log shows the following info
Transforming ‘folder\Web.sitemap’ using ‘folder\Web.Release.sitemap’.
Transforming ‘folder\Web.sitemap’ using ‘folder\Web.Release.config’.
File folder\Web.Release.config, line 2, position 2: - Error - No element in the source document matches ‘/configuration’
Which is completely logical since Web.Release.config is not mend to transform the Web.sitemap file !!!
But why does octopus attempt to perform this transform??
I found a workaround which helps me for the moment, but its not something I want to keep live for eternity.
I defined a project variable ‘Octopus.Action.Package.IgnoreConfigTransformationErrors’ with the value ‘true’
This overrules the System Variable with the same name
My deployment now treats the original error now as informational and continues nicely
I haven’t tested this yet but if you untick “Run default XML transform” will the feature configuration Transform still run for the additional transform?
I’ll get something setup in the meantime to test this out.
Sorry I did not respond earlier, I have been away on a little trip
Unticking “Run default XML transform” prevents the error from happening.
Also, when I only use “Run default XML transform” without any additional transforms everything goes fine
It’s the combination of both which is causing troubles, transformation settings used with “Run default XML transform” are inherited by ‘Additional Transforms’ (or there is some hardcoded setting which forces the transform to look for a ‘configuration’ root element.
Thanks for keeping in touch, and I hope you had a great trip!
I’ll jump in here for Adam for the time being, as he’s currently offline as part of our UK-based team. I believe I have accurately reproduced this behavior you’re reporting, but I was hoping to get direct confirmation.
I have enabled both the default XML transform feature along with the additional transforms feature specifying Web.Release.sitemap => Web.sitemap. When the same directory in the package contains both Web.Release.sitemap and Web.Release.config files, it throws the error against the .config file as that is trying to transform an element that does not exist in the Web.sitemap file it’s trying to transform. When I disable the additional transforms feature it does succeed, however the Web.Release.sitemap does not transform Web.sitemap.
Is this the same outcome in your case? I’d be happy to have a look at your verbose task log directly in case it helps and is needed. If you’re still hitting this issue, could you add the debugging variables to your project (OctopusPrintVariables and OctopusPrintEvaluatedVariables, both with value of True) and create and deploy a new release? The resulting task log will be verbose and will give us a good look at everything that’s going on in your case.
Thanks for keeping in touch. Yeah it certainly looks like a bug, so I’d like to discuss this internally which will likely lead to a bug report being lodged. I’ll let you know the outcome. The workaround I was able to do so as to keep both features enabled simultaneously was to separate both of the Web.Release.sitemap/config files into different directories and update the additional transform feature rules to match that change. Unfortunately I believe that is the only workaround, but hoping that might help in some way.
Please let us know if we can help with anything else in the meantime, and I’ll keep you posted.
Thanks for your work and effort. I’ll stick to my ‘workarround’ for the moment (define a process level variable ‘Octopus.Action.Package.IgnoreConfigTransformationErrors’ and set it to true)
This overrules the system wide setting, and everything gets processed just fine.
Not a problem at all, I appreciate you bringing this to our attention. I’m glad to hear you have an acceptable workaround for the time being. Just a quick note that I raised a bug report at the following link which you can track.
Please let us know if we can try to help with anything else going forward!