Yesterday we notices that the arm-template that we are using to create a new app service slot was not able to copy settings from prod-slot to staging-slot. Api version "2016-08-01".
To copy the settings we use a script for type: "Microsoft.Web/sites"
"siteConfig": "[reference(resourceId('Microsoft.Web/Sites', variables('cdWebAppNameTidy')), variables('webApiVersion')).siteConfig]"
I also notice that when I export a template for the prod app-service, siteConfig is empty. Though, the settings are visible in another section "Microsoft.Web/sites/config"...
Anybody know if something thas changed in the api or what is going on?
Microft support are still investigating this issue but it seem that a way to solve this issue is to simply remove the "siteConfig" node since the settings from production slot are copied by default.
I'm still waiting for feedback why the reference above is not working and why this was changed in azure.
Related
I know this is not possible because of the parameter described in this message:
Your app is currently in read only mode because you are running from a package file. To make any changes update the content in your zip file and WEBSITE_RUN_FROM_PACKAGE app setting.
However, if I change the value of this parameter to 0, the code is still uneditable.
My Azure function is using a lot of libraries that I have to deploy everytime I update even a single character in the code.
This is really anoying. I would like to be able to edit my code without wasting 5 ou 10 minutes waiting for all libraries to be downloaded too.
Do I need to remake my Azure function and edit it only on Azure portal to keep the possibility to edit it ?
Is there a way to get the code back to editable status ?
Thank you.
The thing you need to do is to delete the WEBSITE_RUN_FROM_PACKAGE.
I noticed that when we deployed a Function app from local to azure, the app setting WEBSITE_RUN_FROM_PACKAGE would be added by default, which means your code file is in read-only mode, you can not edit it unless you delete the WEBSITE_RUN_FROM_PACKAGE.
But it should work if you change the value to 0, because it works for me. That's weird.
MIcrosoft docs, Run your functions from a package file in Azure, states the valid values for WEBSITE_RUN_FROM_PACKAGE are either 1 or <URL>, not 0. So rather than setting the value to 0, delete the WEBSITE_RUN_FROM_PACKAGE setting completely.
I have deployed a javascript function app using VSTS Continuous Deployment and the function works but you can't see any of the code in the portal and the management screen looks seriously screwed up. By Function state it only has a grayed out garbage can instead of the grayed out enable/disalbe and the function key section is completely missing. The host keys section is empty even though I have host keys. This is frustrating because I can't set any function keys.
Similar to this one.
This probably means that your ARM template is incorrectly setting FUNCTIONS_EXTENSION_VERSION. Please make sure to set it to ~1. See this page for more info.
If your host keys fail to appear after you have deleted and redeployed your function app (I had this issue after upgrade from ~2 to ~3) then ensure all file shares and blob-containers (in used storage account) with the function app name are also deleted before trying redeploy. specifically the following containers:
azure-webjobs-hosts
azure-webjobs-secrets
Only by clearing these was I able to get a clean re-deploy - and host/app keys back again!
Today I saw something really strange with my azure web site. My site was originally deployed using an ARM Template that configured various application settings.
After the initial deploy one of the settings was manually changed via the portal. Today that setting was reverted back to the original value used in the template.
Should that even be possible? I checked audit/activity logs to see if anyone changed it, and the audit logs are empty.
What is going on here, anyone have an idea?
That should not be happening. Azure will never automatically redeploy your ARM template.
Some possibilities that could have led to this:
Someone redeployed your ARM template, which would cause settings to be reset
Maybe when you made the setting change, it was never actually applied, e.g. if 'save' wasn't click, or some error happen.
I'd suggest applying you setting change again, and making sure that it is in fact applied. It should not get reverted by magic.
Looking at the docs, it would appear that this would be super simple...perhaps it's something with my Azure Configuration. I'm simply setting up a demo project in Azure (which will be a Node app). I set up a Web App (have tried standard, basic, and free levels) and try to follow the instructions here which seem very straightforward.
https://azure.microsoft.com/en-us/documentation/articles/web-sites-publish-source-control/
But when I go to "All Settings" on my web app, there is no "Continuous deployment" option under the Publishing settings.
So I thought that perhaps I needed to set my deployment credentials. When I go to Deployment Credentials, it states that I need to create a deployment username and password. But even when I enter credentials that satisfy the requirements, the Save button is never enabled!
Any ideas on what is going on here would be greatly appreciated. I though perhaps it was some kind of regional limitation, but that seems unlikely as I've tried both West and SouthCentral regions. I'm convinced I'm doing something obviously dumb and just missing it.
Thanks!
I just encounter the same issue, no Continuous Deployment option and cannot save deployment credentials. I just switch back to classic portal and set it from there(click the app > go to dashboard > quick glance > Set up deployment from source control). After setting up and then I switch back to the new portal and the option appears. Really weird issue.
Not much to say...I basically deleted and totally cleaned up everything from Azure and started over and miraculously the 3rd or 4th time, the option just appeared.... Not very reassuring...no idea what altered the situation.
Same issue here, but just copy paste deployment hook (Settings/Deployment Source) and add it to the github repository webhooks and it worked.
I created a cloud service and tested it successfully locally. I added service configurations for stage and production. Here is a snippet of my staging-configuration:
and here my configuration-settings:
Then when I publish I set up the deployment as follows:
All this worked like 2 weeks ago. But now he deploys in VS and when I look into Azure Service Configure area it looks like this:
I played a little bit with the "Update development ..."-checkbox on the second screen but the result is the same.
So it ignores all the settings I made and just won't tranistion my configuration to the ine I named "CloudStage". My current Web PI tells me that I use Windows Azure SDK for .NET (VS 2013) 2.3. I don't get the point.
Edit
Some more things I observed:
No WADLogsTable and WADWindowsEventLogsTable is generated automatically in the staging storage.
I deactivated Remote Desktop because it was one of the changes I made to monitor the event log (which wasn't useful here)
I manually changed the connection strings in Azure Portal but it seems as if the worker is totally unaware of the storage (rebooted it with no success).
Edit
I recognized another thing. Here you can see a running deployment of my service:
See the warning-mark on the left? If I go to my Error list this is shown:
This warning is senseless since it tells me that I did everything the right way. My *.Local.csfg-files are pointing to the local storage. So?!?
This seems weird. Please check the in your ServiceConfiguration.CloudStage.cscfg to verify the expected values.
Have you tried updating any other property like Enabling Remote desktop? Does that get updated on your deployment? You should select the "Deployment Update" check box in the publish dialog. Now, when deploying to an existing Cloud Service, it should ask you if you want to replace it.
If you get the Object reference error every time you right click on project, there might be some issue with the Azure SDK set up.
I'm a little bit further now. What I did was:
Deleted all Services in Azure.
Deleted all Storage Accounts in Azure
Removed my Service-Project completely from solution (not the library containing the worker-logic).
Re-added storage-accounts in Azure.
Re-added services in Azure.
Re-added a project in the solution and added the worker-logic inside it.
Builded up all the publishing-stuff again.
Published it.
The first publish ended like the one described in my question. After I checked the "Update development..."-option in properties of my worker it finally took my transitions into the stage!
Now I recognized, that WADLogsTable was still empty. I hit the instance right in server-explorer and choosse "Update diagnostic settings...". There was an option "Transfer period" suddenly set to "None". This explained to me, why my table was empty and after I set it back to "1" my table is filling again!
Another funny thing beside: When I right-click my Cloud-project in the solution I get "Object reference not set to an instance...". When I just click it left and choose Build->Publish it works.
I just hope that I can help somebody with this. Lets see if it's stable now.
Edit: Yesterday it worked - today is still the same issue :-(.
When you get "Object reference not set to an instance.." for a CloudService project you usually have some kind of mismatch. It could be that a setting in the ServiceConfiguration is not defined in the ServiceDefinition. It could also be that there is a publish profile defined in the .ccproj file for the CloudService that doesn't exist. This might also be what is causing your problems with the different configurations.
So it turns out that the problem is completely on client-side. My Visual Studio (now with SDK 2.4) is doing something wrong. I set up a fresh installation with all the stuff needed :-( and there it works perfect. I'll try to determine if one of my extensions is causing the strange "Object reference not set..."-bug.
Repair-Installation of VS does not solve the problem btw.