So during our custom deployment in our grunt build task from time to time the deployment fails with
[...]
Running "cdnify:dist" (cdnify) task
Going through dist/client/index.html to update script refs
(node:6672) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.
✔ bower_components/angular/angular.js changed to //ajax.googleapis.com/ajax/libs/angularjs/1.5.0-beta.1/angular.min.js
✔ bower_components/angular-animate/angular-animate.js changed to //ajax.googleapis.com/ajax/libs/angularjs/1.4.7/angular-animate.min.js
✔ bower_components/angular-cookies/angular-cookies.js changed to //ajax.googleapis.com/ajax/libs/angularjs/1.5.0-beta.1/angular-cookies.min.js
✔ bower_components/angular-resource/angular-resource.js changed to //ajax.googleapis.com/ajax/libs/angularjs/1.5.0-beta.1/angular-resource.min.js
✔ bower_components/angular-sanitize/angular-sanitize.js changed to //ajax.googleapis.com/ajax/libs/angularjs/1.5.0-beta.1/angular-sanitize.min.js
Running "cssmin:generated" (cssmin) task
>> 2 files created. 864.96 kB → 236.81 kB
Running "uglify:generated" (uglify) task
Thread was being aborted.
Thread was being aborted.
I can ensure that the build scripts are working fine locally and even on other cloud hosters like Amazon or Heroku. Even on Azure it works from time to time and thats the frustrating part because we can't reliable reproduce the error. Maybe it is an performance problem (I noticed Azure is horrible slow on nodejs deployments) and a timeout kicks in because the thread is not responding or taking to much time? This is only speculating hope you guys have a better idea.
Can you share your web app name, either directly or indirectly, and the time of one such fail deployment? Maybe we can see what's going on.
Yeah of course: http://ydm.azurewebsites.net/. I guess the error is occuring when I try to deploy a fresh app without bower and grunt dependencies cached by azure. I don't have a specific time because for now I only get the error described in #2088.
It could be related to it being a Free site, which has limited CPU and memory limits. Next time you hit this, can you share the UTC time of the failure? We may be able to tell more from it.
I tried deploying the repo in a Free site and it failed. I then tried in a Standard site and it worked (other than hitting #2088 in the next deploy, but that's separate).
Thank you for your effort. Have to admit this is hard to debug and to track down as a non Azure spezialist. I am a student and trying to use Azure infrastructure for my bachelor thesis (MSSQL Database, PHP-Webservices and AngularJS Client). Is there any chance to get my Free site upgraded to Standard for a limited amount of time without having to pay €63/month (thats far too expensive for research)? Anyway I appreciate your efforts in advance.
I cannot easily do this, but note that you only get billed for the time you use (see https://azure.microsoft.com/en-us/pricing/details/app-service/). So if you want to test with a B1 (Basic) instance for a few hours, it wouldn't cost much (€0.0632/hr).
So I tested it on a basic and standard plan and the error still occurs. The last deployment I made shows this thread aborted error (currently the service is running on standard plan). However the error does not always occur, looks like it is rather random.
[...]
Running "concat:generated" (concat) task
Running "ngAnnotate:dist" (ngAnnotate) task
>> 2 files successfully annotated.
Running "copy:dist" (copy) task
Thread was being aborted.
Thread was being aborted.
One of the reason might cause by SCM_COMMAND_IDLE_TIMEOUT environment variable in your Application settings. By default if you don't specify the value is 60 (seconds). This means that when there's no output from console up to 60 seconds, the thread will aborted and build is failing. I normally set this value to 300 (5 minutes) or more if necessary.
Most helpful comment
One of the reason might cause by SCM_COMMAND_IDLE_TIMEOUT environment variable in your Application settings. By default if you don't specify the value is 60 (seconds). This means that when there's no output from console up to 60 seconds, the thread will aborted and build is failing. I normally set this value to 300 (5 minutes) or more if necessary.