(CI fix) Attempt to fix persistent Windows error

[swyxio]

we're getting this error in CI

FAIL test/tests/tsdx-build.test.js (28.254s)
  ● tsdx build › should create the library correctly

    ShellJSInternalError: EPERM: operation not permitted, mkdir 'D:/a/tsdx/tsdx/stage-build'

      10 |   setupStageWithFixture: (stageName, fixtureName) => {
      11 |     const stagePath = path.join(rootDir, stageName);
    > 12 |     shell.mkdir(stagePath);
         |           ^
      13 |     shell.exec(`cp -a ${rootDir}/test/fixtures/${fixtureName}/. ${stagePath}/`);
      14 |     shell.ln(
      15 |       '-s',

      at ../node_modules/shelljs/src/mkdir.js:83:12
          at Array.forEach (<anonymous>)
      at Object._mkdir (../node_modules/shelljs/src/mkdir.js:59:8)
      at Object.mkdir (../node_modules/shelljs/src/common.js:384:25)
      at Object.setupStageWithFixture (fixtures/util.js:12:11)
      at Object.<anonymous> (tests/tsdx-build.test.js:37:10)

  ● tsdx build › should clean the dist directory before rebuilding

[swyxio]

@agilgur5 i think this solves it.. just a permissions issue from whatever container we get assigned i'm guessing. its random because github probably swaps out containers randomly based on usage. i'm not a windows/filesystem permission expert - do you think this is ok?

[agilgur5]

I'm actually not sure if this is windows related (though you've seem more PRs than me), because the error I got in #400 is on Ubuntu 😮 😖 c.f. #400 (comment)

[agilgur5]

@agilgur5 i think this solves it.. just a permissions issue from whatever container we get assigned i'm guessing. its random because github probably swaps out containers randomly based on usage. i'm not a windows/filesystem permission expert - do you think this is ok?

So I'm not sure if this would actually solve the issue. While the fix potentially makes sense for an EPERM error, it just randomly popped up in the middle of testing -- the test before this one ("should compile files into a dist directory") somehow passed, despite using the same setup function 😕 😕

GitHub Actions seem to run on full VMs, but in any case, filesystem permissions are normally set during image creation (or like during init or by an operator), and these all run on the same image, so they should have the same permissions 😕 The non-determinism of these filesystem errors is very perplexing

I also found that #391 had the same failure as #400 , which is the same as the one I described in #367 (comment) , a missing .d.ts file. And both of those are on Ubuntu (and it occurred for me on macOS locally). Should probably file a separate issue for that now that it's showed up at least 3 times, but these might all be related.

[swyxio]

problem is now i dont know if this solution does anything at all, and if the Ubuntu problem is the same at all. I'll just close this for now and study the situation a little more.

[agilgur5]

Would have to run like a fuzz test 100x+ times to somewhat test it since these errors are non-deterministic 😕 I think it would be good to have a running list of each test failure that reproduces this for analysis. And possibly send that list to GitHub support to take a look 😅

[agilgur5]

Speaking of, this EPERM error was repro'd in:

• https://github.com/jaredpalmer/tsdx/runs/369303299 and
• https://github.com/jaredpalmer/tsdx/runs/365756928
  (both are merge commits on master)

[agilgur5]

Ubuntu error with .d.ts missing was repro'd on master at:

• https://github.com/jaredpalmer/tsdx/runs/373979788

EPERM repro'd on master at:

• https://github.com/jaredpalmer/tsdx/runs/373978737

[jaredpalmer]

Can you make a PR to fix the error outside of the refactor PR?

[agilgur5]

Can you make a PR to fix the error outside of the refactor PR?

@jaredpalmer not sure if you were referring to me, but I haven't fixed these two issues in any PR nor know what the root cause is. The missing .d.ts I've seen locally a few times and in CI on Ubuntu and macOS, so that one doesn't seem to be CI-specific

[agilgur5]

Just noting here that the missing .d.ts errors (a little different than the subject of this issue), which were happening nearly every CI run, were fixed in #504