I’m using the community step template Deploy Azure Function. In the slot field, I have a bound variable specified. In the deployment logs, I see reference to the correct slot name but the deployment always overwrites the “production” slot. I can share logs privately.
Hi David,
Thanks for getting in contact with us, and sorry to hear you’re experiencing that unexpected behavior.
I was wondering if you could provide a link to the community step template you’re using? Apologies, but I’m not able to find one matching the name you’ve provided. Possibly it’s this one? https://library.octopus.com/step-templates/03bb1a08-52be-43ad-bdfd-117eb562b414/actiontemplate-azure-functions-deployment
You might also consider turning on variable logging if you haven’t already to see that the referenced variable is evaluating correctly in the logs. You can find how to do that in our documentation: How to turn on variable logging and export the task log - Octopus Deploy
Forgive me for asking a basic question, but if the Azure function is created prior to running the step, have you created the slot prior to using that function? I’m not sure if this is required for the template, but it could be worth verifying.
You can direct message me the logs for review if you like, and I’m looking forward to hearing back from you.
Best,
Patrick
Hey Patrick,
It looks like I misspoke… it’s a custom step template derived from the out-of-the-box “Deploy an Azure Web App (Web Deploy)” template. After reviewing the templates that you guys offer, I noticed that there is another option that I have not yet tried (“Deploy an Azure App Service”) which looks like it’s a bit more modern.
Nonetheless, the issue does not appear to be variable-related. The deployment works fine when not specifying a slot but fails when the slot is specified. And yes, the slot exists already. The logs of the deployment even indicate it’s deploying to the slot. But the outcome is that the “production” (default) slot’s app gets overwritten and nothing deploys to the “staging” slot.
The one thing I’ve noticed is that in your docs, there is a curious comment that may be impacting our deployment.
You can choose to specify the slot directly on the deployment target, or directly on the step (if you wish to deploy to multiple different slots on the same Web App Service, for example), however, the slot on the target will take priority.
The slot is indicated on the step, not the deployment target itself. This comment almost implies that specifying a step-level slot will never work because the deployment target’s slot is (intentionally) left blank. Assuming this overriding behavior works as advertises, that would explain why it deploys to the blank (default) slot. Certainly that cannot be the desired behavior.
As for sending you the logs, how do I dm you?
Thanks,
David
Hi David,
Thanks for getting back to me and sending through your logs (I’ve received them).
The Deploy an Azure App Service step is quite a bit better and since you’re on a modern version of Octopus, it’s better to use this step instead if it looks like it will work for your use case. More details can be found here: Azure web apps - Octopus Deploy
That is strange behavior on which slot is being selected, and your logs indeed show ‘staging’ has been selected in the step. Sorry to ask another basic question/clarify, but is ‘Azure Web App Slot’ blank under your desired Infrastructure > Deployment target? I think you indicated this, but just making sure.
The documentation isn’t very well worded, but what it’s getting at is if you were to define a slot on both the deployment target and in the step, for example:
Azure deployment target slot: ‘staging’
Azure deployment step slot: ‘production’
Then the deployment target slot would override what’s been defined in the steps, but otherwise if it’s blank, the step’s slot is selected. I believe this is in line with your expected behavior. So for the above example, the slot to be deployed to would end up being ‘staging’. In the case where the deployment target slot is blank, the slot deployed to should be ‘production’.
You could be encountering a bug here, but I’m curious to see if the new step template changes the behavior or if there is anything defined in the slot for the deployment target. I’m looking forward to your response.
Best,
Patrick
Hey Patrick,
Thanks for the reply. Your clarification on expected behavior makes sense and is what I would expect. I don’t think the new step type was available when I set this stuff up initially. I will try it out today and follow up after the fact.
Thanks!
Hey Patrick, I’ve tried the new step and made some progress but now I have a new issue. First, it appears that it’s not possible to “configure features” on this step type. On my other step, I had specified to run PowerShell Core (I have 7.1.3 installed on the server). The default that Octopus uses is 5.1. Whereas that’s not ideal, it’s not the real problem, however. The new issue that I cannot resolve is that the function host will not start. In the Azure Portal, I can see the functions listed so it seems that the physical deployment was successful. However, I’m not sure how to resolve the host issue. When I click on “Diagnose and Solve Problems”, the blade just spins and never loads. My “production” slot function works fine. So I’m not sure what’s different with the one deployed to the “staging” slot and I’m not sure how to troubleshoot it.
Hi David,
Thank you for following up and for the update. Firstly I have not been successful in reproducing the first issue around ignoring the slot when deploying a function app via the web app step, though that might not be of too much importance regarding your current issue at the moment. I just wanted to address your great question around the precedence of the slot as set on target and step:
This comment almost implies that specifying a step-level slot will never work because the deployment target’s slot is (intentionally) left blank. Assuming this overriding behavior works as advertises, that would explain why it deploys to the blank (default) slot. Certainly that cannot be the desired behavior.
I gave that a test, as I would agree it wouldn’t be the desired or correct behavior. Good news is when not specifying a slot on the target doesn’t automatically default to the Production slot, but that just means no slot is selected. So the step’s slot selection of “Staging” will still be targeted.
I’m currently working on setting up a reproduction environment to see if I can hit this same issue of the function app not starting when using the new step. For now, would you be willing to send another log file, this time from the new issue you’re facing, so we can look at this closely? The most helpful would be to turn on debugging variables in your project, and create and deploy a new release where you repro this same issue, and there will be lots more details written to the resulting task log which might end up being very helpful. 
I look forward to hearing back and getting to the bottom of this one!
Best regards,
Kenny
Hey Kenny,
Thanks for following up. I have a theory on why the app is not starting. At first, I was concerned that it might have something to do with a failed deployment (as I was experiencing with the Web App step type). However, I think the issue now has to do with how I provisioned the slot. I spent all day scouring the internet and testing stuff. Hold off on investing in a repro for now. Let me first determine if this is related or not to Octopus. I currently suspect it’s not now that I’ve migrated to the App Service step type.
I will follow up when I know more.
Thanks!
Hey guys,
I’m still working on resolving my issue. I have discovered the cause of my most recent roadblock. After converting my deployment step from “DEPLOY AN AZURE WEB APP (WEB DEPLOY)” to “DEPLOY AN AZURE APP SERVICE”, I have found that I do not have the ability to configure features (specify Powershell version) or Azure Scripting Tools (use Azure tools pre-installed on the worker). These are critical issues that have caused a regression in our deployments.
Is there a way to do this or do I need to fall back to using the web app (vs app service) deployment type? I seem to have come to an impasse.
Hey David,
Thanks for getting back to us and sorry to hear the issue has caused a regression in your deployments.
One option to work around this would be to use a custom execution container with the tooling you’d like to use specified in a dockerfile. We have some great documentation on how to do this in Execution containers for workers - Octopus Deploy.
As mentioned in the documentation, the easiest way to get started is to work from the worker-tools image.
The advantage to using this method is that you’ll have more control over tooling on your worker, and your worker will always be built from the same image.
Does that seem like it might work for your use case? Let me know if not and I’ll see what other suggestions we can provide.
Best,
Patrick
Hey Patrick,
Thanks for the suggestion but I’m going to hard pass on Docker. I’ve worked around the issue for now. It would be very useful for you guys to add those two missing options to the App Service deployment step type. I’ve run into a new snag that appears to be a bug in Octopus. I will create a new ticket for it. This one can be closed. Thanks.
New issue: Octopus fails to pull the correct package versions when more than one package is referenced
Hi David,
Thanks for getting back to me and letting me know, and I’m glad to hear you were able to work around the issue for now.
I don’t have a definite timeframe for you, but I can say that the option to use tools installed on the worker for the Deploy an Azure App Service step will be included in our 2021.2 release, so if upgrading is a plausible option for you, it’s worth keeping an eye out for that in the next few weeks.
We will work with you on your other thread to hopefully resolve that issue, and thanks for letting us know we can close this one.
Best,
Patrick
That’s great. I will upgrade as soon as it’s available. Thank you.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.