Deployed code messes up the symlinks and app can't start

[danechitoaie]

I'm deploying a nodeJS app with Github actions and it seems that once the code gets to the azure web app server the symlinks from within node_modules/.bin folder are all messed up and app doesn't start.

For example when I run my code locally, if I do a node ./node_modules/.bin/next --help it works, and ./node_modules/.bin/next is actually a symlink to ../next/dist/bin/next

But after code is deployed on Azure with the webapps-deploy action it seems that ./node_modules/.bin/next is no longer a symlink to ../next/dist/bin/next but it actually becomes a text file with ../next/dist/bin/next as its contents and so if I connect to ssh to the Azure server and run node ./node_modules/.bin/next --help (same command I run locally, or that also works ok inside the GitHub action, there I get an error:

/home/site/wwwroot>node ./node_modules/.bin/next --help
/home/site/wwwroot/node_modules/.bin/next:1
../next/dist/bin/next
^

SyntaxError: Unexpected token '.'
    at wrapSafe (internal/modules/cjs/loader.js:1047:16)
    at Module._compile (internal/modules/cjs/loader.js:1097:27)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1153:10)
    at Module.load (internal/modules/cjs/loader.js:977:32)
    at Function.Module._load (internal/modules/cjs/loader.js:877:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:74:12)
    at internal/main/run_main_module.js:18:47

[toy0605]

same issue here

[0gust1]

Had same kind of issue too.

In my case I have a dependency that is a symbolic link to another folder of the repo (it's a monorepo).

Root cause may be linked to the App service sandbox model : https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox#symbolic-link-creation

I did a quick and dirty workaround in my github action, just before the azure/webapps-deploy step.

- name: HACK - copy symbolic link to directory (Azure & symbolic links...)
      working-directory: ./backend
      run: cp -Lr node_modules/dependency/symlinked node_modules/dependency/symlinked-COPY && rm node_modules/dependency/symlinked && mv node_modules/dependency/symlinked-COPY node_modules/dependency/symlinked

[aksm-ms]

@danechitoaie is the action passing successfully? Can you please send the workflow and detailed logs?

[danechitoaie]

@aksm-ms Yes, the action was passing successfully. I've since then moved to Heroku so I can't reproduce or test this anymore but basically the build on GitHub actions side was fine and successful. Problem is that then the GH action was doing a ZIP of the files (node_modules included) and then transferring the zip to Azure and then unzipping them there. This operation messes with the "sym links - https://en.wikipedia.org/wiki/Symbolic_link". So on GitHub actions (before the ZIP process) the symbolic links from within node_modules/.bin are OK, after transferring the ZIP to Azure and unzipping the file the symbolic links are broken.

See this answer from here https://askubuntu.com/a/1203934/606393 I think this could be the solution to this problem.

The ZIP format supports storing the symbolic link. To store symbolic links as such, you can use the --symlinks option.

I haven't tested this, but it's a good lead to start from.

[aksm-ms]

@danechitoaie i understand the issue is with symlinks, i am trying to figure out if the action code is failing or failure is on app service platform side.
From your description of problem, it was unclear if the action passed/failed without proper logs.
Since action passes, looks like issue is at the backend APIs which we use, will look it and update.

Also, it would be great if you can share any workflow run related info to debug like link to your workflow run, downloaded logs, etc.

[aksm-ms]

zip deploy is handled by backend ZIP deploy Kudu API. There is already an issue on Kudu repo tracking this - projectkudu/kudu#2946 .
Please follow up with symlinks related issues on Kudu repo since action is using the same for ZIP deploy.

[reflash]

Had same kind of issue too.

In my case I have a dependency that is a symbolic link to another folder of the repo (it's a monorepo).

Root cause may be linked to the App service sandbox model : https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox#symbolic-link-creation

I did a quick and dirty workaround in my github action, just before the azure/webapps-deploy step.

- name: HACK - copy symbolic link to directory (Azure & symbolic links...)
      working-directory: ./backend
      run: cp -Lr node_modules/dependency/symlinked node_modules/dependency/symlinked-COPY && rm node_modules/dependency/symlinked && mv node_modules/dependency/symlinked-COPY node_modules/dependency/symlinked

Have you found any other solution since then? I'm facing the same problem with monorepo - my symlinks seem to be plain files with path to workspaces (but fail once node tries to import them)

[carterm]

npm install $(npm pack <folder> | tail -1)

https://stackoverflow.com/questions/21425980/npm-install-without-symlinks-option-not-working

[alper-batioglu]

I do not know what the current situation here is but I wanted to add just another dirty fix to this thread.

you can run the action below just before azure/webapps-deploy, which also seems to do the trick for your symbolic links under "node_modules/.bin" folder.

• name: rebuild
  run: npm rebuild

[aaronrogers]

I do not know what the current situation here is but I wanted to add just another dirty fix to this thread.

you can run the action below just before azure/webapps-deploy, which also seems to do the trick for your symbolic links under "node_modules/.bin" folder.

• name: rebuild
  run: npm rebuild

I ran into this problem with my Azure DevOps pipeline. My quick and dirty solution was to add npm rebuild && ... to the beginning of my npm start command. There's probably a better way to deal with it, but I needed it done.

[pkellyuk]

ths is still an issue