@tgoldenberg @oakmad Taking a look at the moment, in the meantime: can you please open an issue on the Github repo.
Just released v1.4.0 with support for the setting āMETEOR_AZURE_NOCACHEā which will clear the cache pre-build when set to any value. I think that should solve your problem, but otherwise please go ahead and open an issue.
Thanks, it looks like something failed on the meteor initially, setting this flag cleared it up
Sometimes if the build is interrupted you can end up with a corrupted installation (not really any different from local Meteor though )
Glad to hear thatās sorted.
Oh and make sure to turn it off for future builds (to avoid excessively long build times)
@ramijarrar Just curious, have you tried the Web App service for Linux? It looks like it offers the same benefits as the regular Web App, but without the awkwardness of Windows for us Linux peopleā¦ Might be nice to add to the repo a deploy.sh that supports the Linux environment as well
So this works great, we got it up and running. The one thing I notice is that if Iāve already deployed and Iām using the site, and then I schedule another deployment with git push azure master
or whatever, right around the āmeteor-azure: Deploying bundleā phase, the site becomes inaccessible (or just shuts off). How do get around that?
@ramijarrar
Here are some other questions (not all related to the repository, but mainly around using Azure Web App with Meteor:
-
Does the deployment script take a long time for you? Iām getting times over 30 minutes for a single deploy.
-
What process do you use for testing? I am using the local Git process since I was getting errors linking with Github. What I have worked out now is to create a Deployment Slot, deploy to it, then view it, and then deploy to the production slot.
-
How do you access your logs? Previously, I could access these easily on a VM by
less
ortail
ing them. Have you found a setup that works for you with the Azure Web App?
Thank you so much!
If you can replicate this behavior with the latest release, please go ahead and open an issue.
New builds should definitely be queued without affecting the active deployment.
Regarding your questions about Azure Web App with Meteor:
-
The latest release (v1.4.4) should cut down build times by up to a factor of 3 (we have considerably large apps now deploying in ~8-10m down from at least 30-40)
-
If youāre referring to basic exploratory testing before pushing to production: you should consider setting up blue-green deployments by using the swap feature to automate switching a staging slot into production without downtime.
-
You can stream logs under āMonitoring > Log streamā in the portal or by accessing the Kudu service (use an external tool if you want to store and search e.g Logentries)
For future reference: Microsoft has pretty extensive documentation for App Service (as well as Kudu, if you want to learn more about the platformās internals)
Does it mean, we donāt need to demeteorize, or use MUP etc ? Can we use the project src code directly in Git repository with just the config scripts folder ?
Update: Weāve just released version 2, which has been rewritten as an npm CLI to eliminate many UX pain-points and address some of the issues people faced with server-side bundling (see full announcement here).