[QUESTION] Updating already published build on azure deletes root folders and files.

[simplecommerce]

Hi,

I am using your package to deploy instances to Azure and I have noticed the following.

I had a public/ folder with image files inside and when I updated the build with my changes, the public folder no longer exists.

Is it possible that the build deletes all files and folders from the root?

If yes, can this be prevented?

Thanks!

[ramijarrar]

Files in /public are served from wwwroot/programs/web.browser/app (as visible in the Kudu console). The build does not modify/delete any local files.

[simplecommerce]

@ramijarrar

Hi, thanks for replying. I am not sure you understood what I meant. These are the steps I did to produce this issue.

1. Create app service.
2. Execute meteor-azure and publish to the app service. (works fine).
3. Create a public/ folder in wwwroot of azure app service and upload some images, like favicon.ico.
4. Do some modifications on meteor app and run meteor-azure again to publish to the same instance.
5. public/ folder with favicon.ico is no longer there on the azure app service wwwroot folder.

The reason why I was uploading files inside a public/ folder on the app service instance, is per azure's iisnode config file that has a rule to allow IIS to servce files in public/ folder directly instead of letting nodejs serve them.

[ramijarrar]

Yes - Meteor maps files in public/ to /programs/web.browser/app/ during the bundling process - this can be viewed in the Kudu console under wwwroot.

During the server initialization process, any files that are no longer present in the new bundle are deleted from your instances to ensure consistency. Adding new files to the public directory will not be served automatically (see https://github.com/meteor/meteor/issues/5008).

Node process is never used for static files, if you take a closer at the default web.config we use the rewrite module to let IIS serve these (also worth reading about IISNode which powers all of this).

[simplecommerce]

Ok i understand, thanks!! @ramijarrar

One thing though, you mentioned that

Node process is never used for static files, if you take a closer at the default web.config we use the rewrite module to let IIS serve these (also worth reading about IISNode which powers all of this).

This part I understand, but if you look at the web.config

    <rewrite>
      <rules>
        <!-- Do not interfere with requests for node-inspector debugging -->
        <rule name="NodeInspector" patternSyntax="ECMAScript" stopProcessing="true">
          <match url="^main.js\/debug[\/]?" />
        </rule>

        <!-- First we consider whether the incoming URL matches a physical file in the /public folder -->
        <rule name="StaticContent">
          <action type="Rewrite" url="public{REQUEST_URI}"/>
        </rule>

        <!-- All other URLs are mapped to the node.js site entry point -->
        <rule name="DynamicContent">
          <conditions>
            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="True"/>
          </conditions>
          <action type="Rewrite" url="main.js"/>
        </rule>
      </rules>
    </rewrite>

As I understand it, this means that any files within public/ folder is handled by IISNODE and anything else is forwarded to main.js which is meteor nodejs in this case.

So that would mean that anything in /programs/web.browser/app/ would be handled by meteor nodejs in this case, since it is not located in the root public/ folder no?

I don't see any lines in the web.config that actually maps the public folder to that path.

Can you confirm?

On Mon, Apr 29, 2019, 21:11 Rami Jarrar notifications@github.com wrote:

Yes - Meteor maps files in public/ to /programs/web.browser/app/ during the bundling process - this can be viewed in the Kudu console under wwwroot.

During the server initialization https://github.com/fractal-code/meteor-azure-server-init/blob/master/script.sh process, any files that are no longer present in the new bundle are deleted from your instances to ensure consistency. Adding new files to the public directory will not be served automatically (see meteor/meteor#5008 https://github.com/meteor/meteor/issues/5008).

Node process is never used for static files, if you take a closer at the default web.config we use the rewrite module to let IIS serve these (also worth reading about IISNode which powers all of this).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/fractal-code/meteor-azure/issues/69#issuecomment-487794947, or mute the thread https://github.com/notifications/unsubscribe-auth/AHUBR2LGFEZQSC2ILPJ3MMTPS6MD3ANCNFSM4HJEMRBA .