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

chore(NA): run del with force option on ref_output_cache #94307

Closed
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion src/dev/typescript/ref_output_cache/ref_output_cache.ts
Original file line number Diff line number Diff line change
Expand Up @@ -130,7 +130,7 @@ export class RefOutputCache {
}

this.log.debug(`[${relative}] clearing outDir and replacing with cache`);
await del(outDir);
await del(outDir, { force: true });
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The outDir values are all expected to be relative to the repo, in what case would an outDir be outside of the repo and require force?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay I think I found the root cause for this. On the current Node.js version on Windows (probably also happening in previous ones), as soon as we require some file/module that is contained inside a symlink it is treated by Windows like it was on a literally different but still equivalent path. In our case as we require @kbn/optimizer as part of the setup_node_env the problem starts right here. For example, before requiring the optimizer __dirname returns C:\Users\IEUser\Downloads\kibana and after the require it while we are inside of it , it starts returning c:\users\ieuser\downlo~1\kibana. That will also affect the result of REPO_ROOT that we use all over. When running node with --preserve-symlinks it stops happening so I think we are on the right path. Aside from that, I was not able to fully bootstrap on windows as the build for kbn/ui-shared-deps complains about a node_module that is being loaded from 2 different paths by the same reason listed above and I was in fact able to found old issues about this problem nodejs/node#6624 webpack/webpack#2362.

For our Bazel work I was already working on #94046 which might also solve that issue. @peteharverson could you please try that other PR I have open to see if that alternative solution also works for you on Windows?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mistic I gave #94046 a test, but see errors - see #94046 (comment). Let me know if you want me to try anything else.

await unzip(Path.resolve(tmpDir, cacheName), outDir);
await Fs.writeFile(Path.resolve(outDir, OUTDIR_MERGE_BASE_FILENAME), this.mergeBase);
});
Expand Down