[rush] Let's document best practices for WSL + Rush

[octogonz]

Relatively few people are using Windows Subsystem for Linux (WSL) with Rush.

In a recent Zulip thread, @akres encountered some problems where Rush's incremental builds were not calculated correctly:

The incremental build feature works, but sometimes triggers a full rebuild while nothing has changed. That wouldn't be so bad. The flip side of the same issue is that when there is a change, the package sometimes does not rebuild, which makes it largely unusable.

I have done a bit of digging and found that the issue happens in https://github.com/microsoft/rushstack/blob/main/libraries/package-deps-hash/src/getRepoState.ts#L309 getRepoStateAsync

I did some debugging and found that the git status call quite frequently (about 50% of times, for me) returns an empty output, so the hashes, which this function returns, are that of the repo in its unmodified state.

I was pointed in this direction by https://stackoverflow.com/a/55692650 this comment. It seems that the issue really comes from two git commands running simultaneously, because when I tried to play with the code that I have locally and I serialized the calls, the issue disappeared.

Reply to this thread with any wisdom, recommendations, or workarounds for WSL+Rush. Then we can write up a website documentation page providing guidance for best practices with WSL.

[octogonz]

@dmichon-msft said:

I used rush on WSL for quite a while; I only stopped due to migration to GitHub codespaces

The main guidance I would give for WSL is that the only path that should resolve from /mnt is code; everything else needs to resolve from the WSL installation or you are completely undoing any benefits of WSL

i.e. your Git enlistment itself needs to not be in /mnt, etc.

[octogonz]

The Stack Overflow article above talks about issues with inconsistent casing of filenames, which result in git status printing an empty output.

[akres]

Cheers, @octogonz, thank you for the debugging session 😁

I'll just explain, for posterity, the original issue that I've encountered.

I had no special setup in my WSL and I tried to separate it from the host as much as possible (e.g. I had my code the /home, I have appendWindowsPath=false in /etc/wsl.conf, so this definitely has nothing to do with me accidentally exececuting git-for-windows from my WSL.

After some investigation, we found that nothing is mysteriously wrong with Git, but the issue is actually a race condition in https://github.com/microsoft/rushstack/blob/main/libraries/package-deps-hash/src/getRepoState.ts : spawnGitAsync

The function sets up data event handlers for stdout and stderr, but it then only awaits the exit event on the process itself. It is possible for the data and close events of the streams to arrive after the exit event (a late buffer flush, I assume). However, in that case the function will have already returned the empty string that the stdout variable is intialized to.

[iclanton]

@akres - The WSL issue should be fixed in Rush v5.124.7

[akres]

Confirmed 🙂 I've just done the same test on the same repo and it works fine now.