-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Rubocop cache broken in CI #8629
Comments
8 tasks
dvandersluis
added a commit
to dvandersluis/rubocop
that referenced
this issue
Sep 3, 2020
…for each file rather than using mtime. File.mtime is faster, but inconsistent in CI, because in each CI build the mtime changes, which means that the rubocop cache implicitly cannot be used as-is. It's obviously slower to calculate a hash for each file, but this is still more performant (both in memory consumption and iterations per second) than the original.
bbatsov
pushed a commit
that referenced
this issue
Sep 4, 2020
…h file rather than using mtime. File.mtime is faster, but inconsistent in CI, because in each CI build the mtime changes, which means that the rubocop cache implicitly cannot be used as-is. It's obviously slower to calculate a hash for each file, but this is still more performant (both in memory consumption and iterations per second) than the original.
dvandersluis
added a commit
to dvandersluis/rubocop
that referenced
this issue
Sep 10, 2020
koic
added a commit
that referenced
this issue
Sep 10, 2020
Put changelog item for #8629 in correct version
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In #8304, the way that the
rubocop_checksum
was calculated changed, to useFile.mtime
for each file. Unfortunately, this has broken using the rubocop cache in CI, because when the code is checked out for CI, themtime
timestamp for each file is the checkout time (as far as I can find, git is not able to set mtime on checkout).That means that every single CI run as of this change now gets a different
rubocop_checksum
value, and the cache is never going to be useful in CI.I reran the same build multiple times (caching the rubocop cache dir in between) and you can see this in action (again note that there were no code or library changes between runs):
I have confirmed this in CircleCI. I imagine it's also the case in Travis but I don't have a project to check with. This is impactful for us because the time to run rubocop in CI has ballooned from 3-4s with the cache to about a minute without it.
Expected behavior
Rubocop cache should be able to be persisted between CI runs.
Actual behavior
Each CI build gets a new value for
rubocop_checksum
, causing the cache to not be used.RuboCop version
Include the output of
rubocop -V
orbundle exec rubocop -V
if using Bundler. Here's an example:The text was updated successfully, but these errors were encountered: