-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
test(turborepo): Create Cache Tests #5371
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
10 Ignored Deployments
|
bc15cb5
to
2675f33
Compare
🟢 CI successful 🟢Thanks |
2675f33
to
84b08c2
Compare
6aa518f
to
5da6ac7
Compare
c3d0e8b
to
f205209
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I opened this and realised I had a pending comment which seems to be outdated.
let mut encoder = zstd::Encoder::new(&mut buffer, 0)?.auto_finish(); | ||
encoder.write(b"hello world")?; | ||
// Should finish encoding on drop | ||
drop(encoder); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That feels odd to me but it makes sense. Coming from the hash / digest api I am surprised but I guess since the digest apis spit out data when you finalize rather than (I assume) write it as you go it makes sense to have 'implicit finalize' on drop.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah we could require an explicit finalize, but that's too easy to miss imo, so it's probably better to just finalize on drop
@@ -33,8 +34,9 @@ impl CacheReader { | |||
|
|||
pub fn open(path: &AbsoluteSystemPathBuf) -> Result<Self, CacheError> { | |||
let file = path.open()?; | |||
let is_compressed = path.extension() == Some("zst"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably worth discussing here whether we want to check for the zstd magic number as well / instead / as a fallback? It'll be slower in the general case but then we are not dependent on the file name causing issues
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll defer to @gsoltis on that, but we should probably keep the same Go behavior until we're done with the port
f205209
to
0b28534
Compare
✅ This change can build |
Linux Benchmark for ecf5740Click to view benchmark
|
bf3de20
to
0a8c365
Compare
Linux Benchmark for 6070821Click to view benchmark
|
0a8c365
to
398f794
Compare
Description
Tests for creating a cache. These do have different hashes than the Go ones, but I think that's fine since there's no expectation that tar construction or zstd compression is necessarily deterministic.
Testing Instructions