-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Initialize cache directory in isolation #12168
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
Conversation
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.
Thanks a lot @tamird, appreciate the PR!
Left a few comments, please take a look.
Also, please include a changelog entry in changelog/12167.trivial.rst:
cache: ensure supporting files (``CACHEDIR.TAG``, ``.gitignore``, etc) are always created in the cache directory, even in the event of test session being interrupted.
|
TBH I'm starting to see this change as -0: we are changing how the supporting files are being created for little reason (as the original reason for the issue is no longer valid). I fear we will be introducing subtle bugs for little gain. |
The original reason is as valid as it ever was - I saw this symptom on my local machine. It wasn't communicated properly to start, but validity hasn't changed. |
An interruption between But if @bluetech prefers, then definitely move forward with this. |
RonnyPfannschmidt
left a comment
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.
at first glance the proposed mechanism is broken in most linux deployments simply by degrading to copytree on anything that has TMP on tmpfs
Creating and initializing the cache directory is interruptible; this avoids a pathological case where interrupting a cache write can cause the cache directory to never be properly initialized with its supporting files. Unify `Cache.mkdir` with `Cache.set` while I'm here so the former also properly initializes the cache directory. Closes #12167.
bluetech
left a comment
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.
LGTM, thanks!
RonnyPfannschmidt
left a comment
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.
given how temporarydirectory actually is used in our case,
a followup at a later point might want to replace it with a simpler mechanism
good work
|
@nicoddemus could you have a look? I believe this is blocked on your approval. |
|
It is not blocked, I will defer merging to @bluetech or @RonnyPfannschmidt. 👍 |
nicoddemus
left a comment
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.
Ahh my bad, did not realize that.
Relutanctly approving, as I mentioned I'm -0 on this -- need to mark as "Approve" to pass the merge requirements.
|
Now I just need someone to click merge 😄 |
|
Turns out the behavior I was seeing which prompted me to send this PR was in fact caused by |

Creating and initializing the cache directory is interruptible; this
avoids a pathological case where interrupting a cache write can cause
the cache directory to never be properly initialized with its supporting
files.
Unify
Cache.mkdirwithCache.setwhile I'm here so the former alsoproperly initializes the cache directory.
Closes #12167.