I’m working to transition a project from the older “Azure Web App (Web Deploy)” step to the “Azure App Service” step so I can migrate Octopus off a Windows VM and move to the Linux container install. It seems there are a lot fewer options in the newer step including setting a physical path for the package files. Currently, my project deploys two packages to a single app service with two virtual apps set up.
Is there a way with the current step to specify a physical path for one of the packages? I see that the Kudu API offers a “path” parameter for zip deployments along with a “clean” parameter that may also be useful for our use, but they don’t seem to be exposed in the step UI.
Welcome to the Octopus community, thanks for reaching out!
It seems that a decision was made to not support the ‘Path’ parameter in the new “Azure App Service” step as we have found that it’s not quite the same functionality as the previous step “Azure Web App (Web Deploy)” and often causes some additional problems.
I believe that it should be possible to set the desired Kudu Deployment Settings such as, ‘Clean’ and ‘Path’, by using the ‘App Service Configuration’ section, which is a new section in this step.
Thanks for the info. Based on some further investigation where you linked, I’d be wanting to use the “SCM_TARGET_PATH” setting. I’ve tried that, however, and it’s not working fully.
The setting does get applied, luckily, but only after the package is deployed. For future deploys and any tasks after that one, the package is extracted in that subdirectory. This, unfortunately, means that the package deploying isn’t placed in the correct place.
Also, any packages deployed via the “App Service Deploy” step get renamed from “nupkg” to “zip” in the built-in artifact directory in Octopus and break future deploys of that package as Octopus then can’t find the package. Not sure if that’s a known bug or not.
Thanks for keeping in touch! My apologies for the delay in getting back to you. It looks like Finn’s internal request got lost in the shuffle, I’m sorry to say. I know vaguely of some issues in this general area on the new step, which lead to some direct choices to support/not support certain things out-of-the-box like Finn was getting at. This issue you’re seeing might very well be one example, but it would be worth having some engineers who worked on this have a look, so I’ve bumped up the question and will relay back any/all resulting input.
Regarding the package in the built-in feed getting renamed from .nupkg → .zip, that seems completely strange and concerning! I wasn’t able to repro that behavior locally, so I’m hoping you could send us some more info to hopefully figure out what’s going on there, like verbose task log from a deployment running this App Service Deploy step that’s causing this problem.
I look forward to getting to the bottom of these issues.
I’m sorry for the delay in getting back to you, as Kenny mentioned my request got overlooked but has now been answered!
You are correct in needing to use the SCM_TARGET_PATH, however you will need an additional step to set this setting prior to the App Service deployment. e.g. an Az Cli Script Step that will set the SCM_TARGET_PATH value ahead of the deployment. Unfortunately we aren’t able to guarantee that this will continue to work indefinitely, as potential future changes could break this functionality.
I’d be happy to help get this implemented, feel free to let me know if you have any questions or run into any issues!
The package converted from nupkg to zip is being investigated under the following github issue: