Publish: Done executing task "FilterByItems" -- FAILED.

[lrakai]

I'm using VS2012, NTVS 1.1, quad core intel i7 processor and 8GB of RAM. I followed the instructions to publish to an azure website from visual studio here: https://github.com/Microsoft/nodejstools/wiki/Publish-to-Azure-Website-using-Web-Deploy

After clicking publish roughly 4 hours elapsed until the operation completed with no indication of an error. Upon inspecting the website nothing made it to the azure server. From probing the build log I found the culprit to be

Task Parameter:SourceMetadataName=DestinationRelativePath
Task Parameter:FilterBaseOnRelativePath=True
Done executing task "FilterByItems".
Task "FilterByItems"
Done executing task "FilterByItems" -- FAILED.
One or more errors occurred.

========== Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========
========== Publish: 0 succeeded, 1 failed, 0 skipped ==========

Even though it fails to publish, a 3rd build is started, hiding the problem. I was able to follow the same procedure to publish the node express starter app without any issue. By comparing the logs from attempting to publish my app and publishing the express app the failed FilterByItems is the difference. Because it is not acceptable to take hours to publish I will be publishing from local git repo which completes in 15 minutes. I hope there would be some way to bring the publish from inside VS closer to that amount of time and also a fix for the failed FilterByItems task. A verbose build log is attached.
publishlog.txt

[mousetraps]

Interesting... could it be that you're running into MAX_PATH issues? #69 What happens if you move your directory to a shorter path like c:\src?

Re: making web deploy faster in general, unfortunately the way web deploy currently works is that it must copy your node_modules directory, as it doesn't run npm install when your application is deployed as it does with git deploy (presumably you're not checking in node_modules?) which is why we actually recommend git deploy at this time.

That said, we're currently working with the Azure team to improve the deployment experience going forward - I don't have a timeline on that, so don't hold your breath, but stay tuned 😃

[lrakai]

Thanks for the suggestions and information. I came across the MAX_PATH issue before reporting and found the longest absolute path I had was comfortably under 260. It was under 180 chars, but I can try when I am back to work next week, and the node_modules were correctly presumed not checked in.

It was a satisfying experience working with NTVS except for the integrated deploy option. I will inhale and patiently await what the future has in store.

[lrakai]

I gave it another shot from a much shorter src directory. The longest path in the directory was 169 characters long (D:/s/s/obj/Release/Package/PackageTmp/node_modules/main-bower-files/node_modules/globule/node_modules/glob/node_modules/minimatch/test/extglob-ending-with-state-char.js) and over 8 hours elapsed to complete the operation. This time it did not fail on the FilterByItems task and did make modifications to the server. However, the it did not complete and again reported

========== Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========
========== Publish: 0 succeeded, 1 failed, 0 skipped ==========

This was after many VSMSDeploy lines adding directories and deleting files. No files ever got added so the state of the server's directory is a bunch of empty directories so the site reports "You do not have permission to view this directory or page." when accessing in a browser. There is no details on what failed this time in the verbose build output. It simply reports the message above after deleting a directory. I verified that the obj\Release\Package\PackageTmp directory does have all the files needed and not just empty directories. I have attached the build log and replaced long portions of file listings in the output to get the file under the 10MB limit (down from 44MB).

publishlog2abbrev.txt

[paulvanbrenk]

Closing. The whole Azure deployment experience needs to be reconsidered, which we're doing for the next major release of VS. In the mean time, this is the recommended way to publish to Azure.

https://docs.microsoft.com/en-us/visualstudio/javascript/publish-nodejs-app-azure