I have a working azure web app, I cant deploy anything when I click Deployment center it just stuck at Fetching deployment data
If I wait for while I get this:
I have to mention that I had apps before on azure and everything worked smooth.. the only difference between the apps is that the broken app I created with azure VS extension.
all the apps are configured to auto-deploy from Bitbucket
For me, there wasn't enough space on the disk. I saw this "lack of space" error message after clicking Deployments in Kudu (Advanced Tools in your web app). I deleted the LogFiles folder to free up space and everything went back to normal.
I had the same problem with deployment sticking/breaking when I was trying to use the F (free) tier. I was trying to push a .NET Core app with https: support enabled in the app. Because the F tier does not support SSL, it broke everything and there was no trace to say what the problem was. Not sure if this was your problem as well, but if anyone is trying to do the same thing that I did, I hope this is helpful. Changing to an S (standard) tier fixed it. I suppose disabling https: support in the app you are trying to push would work as well, but I did not try that approach.
This happened to me last night. Finished up some changes to an API and front end app. API published to app service without issue from Github pipeline. Front end app would not publish. Error was:
Deployment Failed with Error: Error: Failed to deploy web package to App Service. Conflict (CODE: 409)
Same issue as here. The deploument center would never load and eventually would give me a Gateway Timeout error. Two hours I spent trying to figure out what was wrong. Even opened a support ticket. It was a problem with the Azure service that was resolved by the next morning.
Related
I am trying to use Azure DevOps pipelines to build a .NET 5 (Core) web app and deploy it to my Azure app service. I can't find any complete examples in the documentation that achieve this so I'm following this:
https://github.com/shahedc/NetLearnerApp/blob/main/azure-pipelines.yml.txt
However, the Azure deploy task keeps returning this vague error:
In my Azure portal I only get this error:
I am assuming the issue is in my pipeline because deployment works when I deploy it directly from the Deployment Center in the Azure portal. Here are the details for the 3 relevant tasks my pipeline:
I found the solution. It turns out the issue was not in the pipeline, but was caused by a Git connection to the app service I had previously set up in the Azure Deployment Center. Even though I disconnected/removed this Git connection, there was somehow still a residual file left over in Azure that was causing the error. I deleted the 'deployments' folder in Kudu (pictured below) and the pipeline started working as expected.
Getting to the above pictured view:
Navigate to your Azure Function project
Search for Advanced Tools
Open PowerShell
Check if you have disk space available.
Yesterday we started getting this error, even if we tried to re-deploy packages that were successfully deployed just an hour before. Our system guys checked and found out that we reached the space limit and that it was time to upgrade.
P.S. I know that this was answered a long time ago. I am just sharing the solution that was not mentioned here and that worked for us.
think what Dan Beaulieu said in above answers is correct, but one thing to add, in my case, after deleting the deployments folder, remember to restart the app service/web app, which will make it take effect.
I am using the Devops release pipeline to deploy new releases to my function apps.
However a few days ago, the release pipeline stopped working and I continue to receive the following error message on deployments:
Error: Error: Failed to deploy web package to App Service. Bad Request (CODE: 400)
After digging in the kudu stack trace, I find the following:
Error occurred, type: error, text: No space left on device
However, when I look at my quota usage on the app service plan that hosts my function apps, I have not even exceeded 1% of my quota. I am on a basic app service plan that provides 10gb of storage and my function apps combined have used 50mib.
I am reaching out to see if anyone else has/is currently experiencing this issue and what they did to resolve it.
Many Thanks!
Adam
Some advice for trouble shooting:
You can use the Kudu service to see the size of all the files on the Azure. This way you can further check your storage. Go to Azure portal -> Your_APP_Service -> development tool -> advanced tool to access Kudu service and download the extension. You can click this blog for detailed information.
The issue may be that your source code and output are too large. In this case, try using a self-hosted agent and clear the cache.
The reason for the issue may also be that the packages uploaded at one time are too large, which leads to the shortage of temporary files. Click on the link to see if you have exceeded the temporary file limit.
I had the same problem, I connected with ssh to app service and run:
$ df -h
and scale up (App service plan)(be careful the server IP can change)
And after run the pipeline, Its run Correctly, if you wish you can return to the previous plan.
If anyone encounters this issue in the future this may resolve your problem.
I believe the problem with deployments may have been caused by a corrupt function app in the app service plan. I noticed that the function app I recently added had been categorised as a container although I never specified it as such. Anyway, deleting that function app and recreating it resolved the issue. All deployments to that app service plan are now working fine!
I'm pretty sure i am doing something wrong.
But let me attempt to explain my situation...
I created an Azure App Service with Continuous Delivery configured. So far i see that all my deployments are successful. When i go to my app service URL i see Service Unavailable.
Now i suspect my problem could be related to what is being deployed.
Note that I am using Visual Studio Online for my source control and build system.
The source/repo only has 3 folders:
- A folder called .vscode
- A folder called Tools (a bunch of .net console apps)
- A folder called Service (my node.js based service)
Now, the source builds successfully.
And the continuous deployment, triggered after a queued build, completes successfully.
But when i go to the service url i see the dreaded message "Service Unavailable".
I suspect the problem is related to this:
Basically im not sure what is being deployed here.
What i want to deploy is just the Service folder (my node.js app).
I suspect somehow that the entire source tree is being deployed.
Some additional details:
Http Protocol: HTTPS
Error: 503 - Service Temporarily Unavailable
Any help/insights are much appreciated!
Updates
I am confused if the Continuous Delivery option can deploy the node.js app. I did come across this article which shows how to deploy node.js app via "Push to Azure from Git".
Updates 2
I'm not entirely sure right now because i havent tried this out. But the answer to this question seems to hold the key (it seems like it is exactly what im looking for).
Updated 3
I was able actually get the node.js app to start. The issue was that the .js file is two folders deep (in the Service folder). I updated the "Startup command" setting under the "Deploy Azure App Service" (under Continuous Delivery build definition). Now i can see (from the Kudu Docker logs) that it is running.
The problem im having now is that the node.js app can't seem to conenct to the Azure SQL database (this works when i run locally).
We have a bug in our WebJob running in our live environment, I have identified the bug and fixed it, this I can verify in our Dev-environment. I published my WebJob as a "Azure WebJob" to our live environment but the bug i still present. To add to the confusion the bug now just occurs sometimes. So for some reason the old code is running somewhere sometimes.
Can someone please help me understand this?
I had a similar problem. We deploy using a stage environment in Azure and it turned out that the "old" WebJobs (running code with an old version of the entity framework model) where still running on the queue. These jobs where then fetching messages and consuming them. To add to the problem the exception was consumed in a try catch and the status of the WebJob was success.
Check if you have a stage environment (add -stage to the Webapp name) and if so go in to the Azure management portal and stop them.
Note, it is not enough to stop the Webapp, you must stop the WebJobs directly. This is done (in the new portal) under Settings->WebJobs and then right-clicking on the webjobs name selecting stop.
I spent ages looking into this problem. Turns out I had the web job project running in a console on my PC at work! No matter what I did on Azure the presence of this exe running and using the same storage for the web jobs meant that the old code running on my work PC picked up the jobs before Azure did. Easy fix: just make sure no exes are running outside of Azure!
In our case the web app was published to physical path /site/www instead of the default /site/wwwroot, because of this the Azure web portal interface adds the WebJobs to folder /site/jobs, but the webdeploy via VS or Azure are still trying to publish the webjobs inside the /site/www.
More details at Publishing WebJobs with Azure Pipelines
I am deploying to local azure compute emulator. It goes into a loop displaying: Role state Unknown and Destroyed. I can deploy the same exact code to azure cloud with no issues, but it fails in the local deployment. I checked the fusion log to see if there is any assembly load issues with no avail. How can I chase down such an issue?
OK. It turns out I copied the web.config from the earlier version and it brought the old version of DiagnosticMonitorTraceListener and targetFramework. I guess, this is a pretty common pattern of mistake. Once I fixed them by copying them from a health project, it worked like charm.