Move CARGO_HOME to take advantage of cache

[norepro]

CARGO_HOME is set to build/cargo-home which is inside the workspace. This folder contains the .../registry/src folders. Being inside the workspace makes Swatinem/rust-cache consider it local code and thus deletes the built dependencies at job end, regardless of location.

Move CARGO_HOME outside the workspace so the rust cache considers the build dependencies as non-local.

Helps with #95

[norepro]

Unrequested context: I was researching why Firefox on Linux did not support hybrid web authn, which led to your work here, which I got nosy and looked at the issues and saw CI + help wanted. I like build stuff and figured I'd take a stab!

The first build of this PR will probably have the same timings (~6 min) as the rest, but subsequent builds of this PR or any build after this goes to main should really see a benefit. Maybe down to 3 min or so... I think 😄️

[iinuwa]

Thanks for looking into this! That's a good explanation. I think we could move the entire build directory out of the workspace directory to avoid other similar issues in the future. Does that make sense?

[iinuwa]

I moved CARGO_HOME, and the rest of the build folder, but it still looks like it's using 115 MB of compressed data. I think that makes sense because my local CARGO_HOME is only 300 MB.

One weird thing now is that the target directory is being treated as a relative directory even though it is being passed as absolute (logs). If you're interested in looking more into that, that'd be helpful, but I think I'll leave it for now.

[norepro]

Thanks for looking into this! That's a good explanation. I think we could move the entire build directory out of the workspace directory to avoid other similar issues in the future. Does that make sense?

It's a good idea for general cleanliness! It would have still missed this particular cache miss, though, because the rust cache looks at the location of the source of the dependency (under CARGO_HOME) instead of the actual dependency output location (build/target). In other words, if you moved the build target folder and not CARGO_HOME, this bug would still exist.

If you do move the build folder, remember to update the workspaces: ". -> build/target" line in your YAML.

I moved CARGO_HOME, and the rest of the build folder, but it still looks like it's using 115 MB of compressed data. I think that makes sense because my local CARGO_HOME is only 300 MB.

That's correct. I incorrectly correlated the size of the "local" sources (hundreds of MB) with the size of their outputs (gB). I'll remove that line from the description.

One weird thing now is that the target directory is being treated as a relative directory even though it is being passed as absolute (logs). If you're interested in looking more into that, that'd be helpful, but I think I'll leave it for now.

Dug into this, it's because it reports all paths as absolute: https://github.com/Swatinem/rust-cache/blob/7e35be21c2b94d972b1143087fabc27d7dc881ef/src/config.ts#L155 . I searched its source for "cache paths" from your log, found it used the target of the workspaces, and found that line where said target is set, fully qualified every time. Cosmetic :)

[iinuwa]

Dug into this, it's because it reports all paths as absolute: https://github.com/Swatinem/rust-cache/blob/7e35be21c2b94d972b1143087fabc27d7dc881ef/src/config.ts#L155 . I searched its source for "cache paths" from your log, found it used the target of the workspaces, and found that line where said target is set, fully qualified every time. Cosmetic :)

Yeah, that's the problem, it treats absolute paths as relative when it should be treated absolute. That should probably be filed as an issue upstream.

I think that means that there's not much left to do with CI after #195, so I'll close this. Thanks for the research!