Prefer zstd over gzip #270
Conversation
|
Awesome @aiqiaoy!! I will review this PR soon |
|
Perhaps you should pick this commit (c7743bc) change to make the test work correctly. ( |
src/cacheHttpClient.ts
Outdated
| @@ -82,12 +83,11 @@ function createHttpClient(): HttpClient { | |||
| ); | |||
| } | |||
|
|
|||
| export function getCacheVersion(): string { | |||
| export function getCacheVersion(useZstd?: boolean): string { | |||
This function is a "boolean-trap". It might be worth considering using an enum here, like:
enum CompressionTool {
Zstd,
GnuTar
}Well, in my opinion, this is not a big deal. The enum has mistakes, depending on how you look at it, and should not be actively recommended for use. If you want to avoid use boolean, you should use string literal types combine with union types. But it's too overkill for this purpose. So, there is no problem with the current code.
Never said that it is a big deal :)
I was more coming from a readability-PoV because the first change I saw in the PR diff was:
test("getCacheVersion with zstd compression returns version", async () => {
testUtils.setInput(Inputs.Path, "node_modules");
const result = getCacheVersion(true);
expect(result).toEqual(
"273877e14fd65d270b87a198edbfa2db5a43de567c9a548d2a2505b408befe24"
);
});and I didn't understand what getCacheVersion(true) means, hence the comment about boolean-traps :)
Sorry. This kind of expression is really common in Japanese, So I said. (English is still difficult for me...) It certainly seems to have a readability problem, but I think it's basically within the acceptable range.
If this needs to be changed, I suggest a major redesign, but it requires too much work and this action probably won't be a large codebase that it needs.
PR updated to use enum instead.
|
@aiqiaoy This should work. const args = [
...(useZstd ? ["--use-compress-program", "zstd -T0 --long=31"] : ["-z"]),
"-xf",
archivePath.replace(new RegExp("\\" + path.sep, "g"), "/"),
"-P",
"-C",
workingDirectory.replace(new RegExp("\\" + path.sep, "g"), "/"),
]; |
|
This isn't a tar problem, it's a strange specification of Node.js. |
@imbsky Thanks! Nodejs newbie here and you definitely saved me a lot of headaches lol |
|
My pleasure. I had the same experience before when implementing this hehe... |
|
The format check seems to have failed. |
|
Oh, all tests have passed now. I will review this soon. Perhaps you are also interested in doing that. @joshmgross |
Looks good overall! Left some clarifying comments
|
All of the following flags are needed for compression, and all of the following flags are needed for a decompression. CC: @kcgen |
|
This explanation by @kcgen is really impressive. |
The doc says the maximum for @joshmgross Do you know if we support 32 bits OS for our self-hosted runners? |
Yep we do. We at least have an ARM32 Runner that's in Pre-Release |
Add zstd to cache versioning
8e1ec33
to
76bba55
|
PR updated. @joshmgross @imbsky It would be great if you can take a look again when you have time :) |
Awesome!
|
This looks good to me! I really appreciate your work! |
|
Thanks everyone for the review and feedback. I'll check this PR in early Monday just to be on the safer side. |
Looks good to me!
|
Thanks @aiqiaoy for doing the rest of the work. |
|
It is way faster, thank you! |
|
@joshmgross Is there anything left to do for the v2 or next v1 series release? |
|
If I remember correctly, the multi path stuff and this were the only remaining tasks for v2. |
We're tracking #263 for v2, but that might be back-ported to v1 as well. |
|
Oh, I see. Will the next version probably be released after the PR is merged? |
|
Well, I just want to check, so there is no rush to do anything. |
Fixes #184
A lot of the work was completed by @imbsky in PR #202. Additionally, this PR adds:
zstdin the cache versionzstdinstalledThe text was updated successfully, but these errors were encountered: