Ref: https://github.com/Shopify/bootsnap/issues/336
Bootsnap was initially designed for improving boot time
in development, so it was logical to use `mtime` to detect changes
given that's reliable on a given machine.
But is just as useful on production and CI environments, however
there its hit rate can vary a lot because depending on how the
source code and caches are saved and restored, many if not all
`mtime` will have changed.
To improve this, we can first try to revalidate using the `mtime`,
and if it fails, fallback to compare a digest of the file content.
Digesting a file, even with `fnv1a_64` is of course an overhead,
but the assumption is that true misses should be relatively rare
and that digesting the file will always be faster than compiling it.
So even if it only improve the hit rate marginally, it should be
faster overall.
Also we only recompute the digest if the file mtime changed, but
its size remained the same, which should discard the overwhelming
majority of legitimate source file changes.
Co-authored-by: Jean Boussier <jean.boussier@gmail.com>
Add a test to prove that if there is an error reading a file
the message contains the problematic path.
The custom permission error class and method were designed
to warn about errors with the cache path
but we stopped reporting write errors in
d878622782
and read errors in
503e9d5080
Fix: https://github.com/Shopify/bootsnap/issues/423
When you know that the cache won't be used again, it avoid
some useless work and IOs.
Typically this might be the case for dockerized applications. You
generate a cache when building the image, but then when you boot the
application any cache update won't be persisted, so thre is no point.
This commit makes several changes to the existing test files to support the Windows platform. These changes mainly comprise using Windows file paths or file access methods. There are two tests called out that do not work on Windows at all, and are hardcoded to pass. I would have used 'pending', but I could not find out how to do that in minitest.
Co-authored-by: Daniel Rikowski <daniel-rikowski@users.noreply.github.com>
Currently, users get:
Permission denied - bs_fetch:atomic_write_cache_file:open.
This is not actionable: it doesn't even include the path which was
denied access. Here we at least present the paths we failed on.
```
.......a.rb:1: warning: assigned but unused variable - a
...a.rb:1: warning: assigned but unused variable - a
..a.rb:1: warning: assigned but unused variable - a
.a.rb:1: warning: assigned but unused variable - a
..a.rb:1: warning: assigned but unused variable - a
.a.rb:1: warning: assigned but unused variable - a
..a.rb:1: warning: assigned but unused variable - a
..a.rb:1: warning: assigned but unused variable - a
a.rb:1: warning: assigned but unused variable - a
..a.rb:1: warning: assigned but unused variable - a
.......................
```
When opening a previously generated cache file, we will
now open the file as read-only. Consumers of this method
never wrote to the file descriptor and opening as read-only
enables us to avoid needing write permissions on the cache folder.
Earlopain
Jean Boussier
Étienne Barrié
Randy Stauner
James Pogran
alebruck
Burke Libbey
Aaron Patterson
Adam Jacques
Will Jordan
Sam Saffron