It looks like
Octopus.Action.Azure.PreservePaths variable does not work as documentation states:
I would like to preserve
ComponentA but not
Unfortunately, setting variable to
\\Components prevents both parent and child directories from being deleted. Therefore, if I set variable to
\\Components;\\Components\\ComponentA(\\.*|$) as documentation states, both
ComponentB directories are preserved.
I have tried to configure the variable many ways without success. Any hint how to make it work, please?
Octopus version 3.11.11
Thanks for getting in touch. Could I just confirm that you have the “Remove additional files” option checked? The variable only comes into play when that setting is checked, otherwise all folders are preserved anyway.
If you do have that setting checked then there is a bug. If that is the case could you please attach a screenshot of the process step configuration so I can set up an exact replica for testing?
Yes, the option is checked, other directories are being correctly removed from destination. Screenshot attached (Deploy an Azure Web App from Octopus Server (built-in) step details + enabled features).
Apologies for the delay. I’ve set up an Azure Web App deployment based on what you’ve described and have been able to replicate the behavior. This was working as described in the documentation at the time of publishing, so it seems like there has been a regression at some point that we hadn’t picked up. We’re investigating at the moment to try to determine why the behavior changed and when.
I did set up some other scenarios and found that you can get it to correctly keep Component1 and remove Component2 if they are both folders directly off the site root folder, rather than having a common Components folder in between. You then just need to set the variable to \Component1. This may or may not be a viable workaround for you until we can get a fix implemented, but thought I’d mention it in case.
We do hand these path in to WebDeploy itself, so we suspect something has changed when we updated an SDK version or something. I’ve created an issue in GitHub which you can follow.
Thank you for creating an issue.
Do you have any estimate of when I can expect it to be fixed?
Sorry we don’t have any estimate on that at this point.