[SERVER-33110] SCons CacheDir should re-use pre-computed signature data Created: 03/Feb/18 Updated: 28/Aug/23 Resolved: 28/Aug/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Build |
| Affects Version/s: | None |
| Fix Version/s: | 6.0 Desired |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Andrew Morrow (Inactive) | Assignee: | [DO NOT ASSIGN] Backlog - Server Development Platform Team (SDP) (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Server Development Platform
|
||||||||
| Participants: | |||||||||
| Description |
|
Currently, signature information is not preserved when entries are added to the cache. That means that when entries are extracted from the cache, we need to re-compute, requiring a file traversal and MD5 computation. Instead, insert the signature along side the cache entry, and re-use it when extracting. |
| Comments |
| Comment by Andy Schwerin [ 07/Feb/18 ] |
|
I don't know, either, but editing a file during the build leads to a state where just rerunning the same build command again fixes your problem. A corrupted file in the cache lives until you think to blow out the cache, and you may never understand the root cause. I wonder if there's a solution where we cache the md5 values, but then confirm that they're up-to-date only when we're consuming the file anyhow, and thus reading it into cache is harmless. |
| Comment by Andy Schwerin [ 05/Feb/18 ] |
|
Does this change the guarantees requires of entries in the cache? Presumably, now, a change to a cached file that occurs outside scons (human error) will get detected by Scons and dealt with. |