Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ERROR] Directory not empty (os error 39) on build in docker #84

Closed
nnmrts opened this issue Sep 2, 2023 · 2 comments · Fixed by #107
Closed

[ERROR] Directory not empty (os error 39) on build in docker #84

nnmrts opened this issue Sep 2, 2023 · 2 comments · Fixed by #107

Comments

@nnmrts
Copy link

nnmrts commented Sep 2, 2023

When running

deno run -A --no-check --unstable main.js

in a fresh project in a Docker environment, it fails with this:

#0 19.00 ✘ [ERROR] Directory not empty (os error 39): rename '/tmp/d2d1db33' -> '/root/.cache/deno/deno_esbuild/clsx@2.0.0/node_modules/clsx' [plugin deno-loader]
#0 19.00 
#0 19.00     islands/piece-display.jsx:10:17:
#0 19.00       10 │ import clsx from "clsx";
#0 19.00          ╵                  ~~~~~~
#0 19.00 
#0 19.05 ✘ [ERROR] Directory not empty (os error 39): rename '/tmp/911cbde1' -> '/root/.cache/deno/deno_esbuild/clsx@2.0.0/node_modules/clsx' [plugin deno-loader]
#0 19.05 
#0 19.05     components/input/button.jsx:1:17:
#0 19.05       1 │ import clsx from "clsx";
#0 19.05         ╵                  ~~~~~~
#0 19.05 
#0 19.29 error: Uncaught (in promise) Error: Build failed with 2 errors:
#0 19.29 components/input/button.jsx:1:17: ERROR: [plugin: deno-loader] Directory not empty (os error 39): rename '/tmp/911cbde1' -> '/root/.cache/deno/deno_esbuild/clsx@2.0.0/node_modules/clsx'
#0 19.29 islands/piece-display.jsx:10:17: ERROR: [plugin: deno-loader] Directory not empty (os error 39): rename '/tmp/d2d1db33' -> '/root/.cache/deno/deno_esbuild/clsx@2.0.0/node_modules/clsx'
#0 19.29   let error = new Error(`${text}${summary}`);
#0 19.29               ^
#0 19.29     at failureErrorWithLog (https://deno.land/x/esbuild@v0.18.11/mod.js:1615:15)
#0 19.29     at https://deno.land/x/esbuild@v0.18.11/mod.js:1027:25
#0 19.29     at runOnEndCallbacks (https://deno.land/x/esbuild@v0.18.11/mod.js:1450:45)
#0 19.29     at buildResponseToResult (https://deno.land/x/esbuild@v0.18.11/mod.js:1025:7)
#0 19.29     at https://deno.land/x/esbuild@v0.18.11/mod.js:1054:16
#0 19.29     at responseCallbacks.<computed> (https://deno.land/x/esbuild@v0.18.11/mod.js:676:9)
#0 19.29     at handleIncomingPacket (https://deno.land/x/esbuild@v0.18.11/mod.js:731:9)
#0 19.29     at readFromStdout (https://deno.land/x/esbuild@v0.18.11/mod.js:652:7)
#0 19.29     at https://deno.land/x/esbuild@v0.18.11/mod.js:1901:11
#0 19.29     at eventLoopTick (ext:core/01_core.js:183:11)
------
Error: failed to fetch an image or build from source: error building: failed to solve: executor failed running [/bin/sh -c deno task build]: exit code: 1

To reproduce, check out this repository: https://github.com/pumpncode/open-match

It uses fly.io as deployment platform and you might need an account there to exactly reproduce this, but maybe just deploying the Dockerfile locally works as well. Below are the steps for fly.io:

  1. create an .env file in the repository root and add PORT=8000 to it
  2. if you're not logged in fly yet deno task authenticate
  3. deno task create-app
  4. fly secrets set PORT=8000
  5. deno task scale
  6. deno task deploy

This may be related to #82 and may be fixed by #83, however I never rename the DENO_DIR in my case, in case this a requirement for this issue to occur.

Running deno task build locally works just fine for me.

@mxdvl
Copy link

mxdvl commented Sep 25, 2023

PR #83 is now ready for review, glad to know I was not the only one experiencing the issue!

@csvn
Copy link

csvn commented Oct 12, 2023

I'm not sure if this is because of Docker. I had a working Esbuild config, then I added another entry-point and encountered the error message described here.

const res = await esbuild.build({
  plugins: [...denoPlugins()],
  entryPoints: [fileA, fileB], // <---- adding file B here produced the error
  outdir: filePath('dist'),
  bundle: true,
  splitting: true,
  format: 'esm'
});

In my case, I had a dependency that was used in both scripts, and it seemed like it was a race condition where both builds started loading the file. I solved it by just runnning Esbuild twice for now, one for each entry. Maybe my experience can help out with this somehow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants