summaryrefslogtreecommitdiff
path: root/src/buildtool/storage/target_cache.hpp
AgeCommit message (Collapse)Author
2025-01-07Add backend description to CAS in a ctor of TargetCacheMaksim Denisov
...instead of adding it preliminarily.
2025-01-07TargetCache: use BackendDescription for sharding instead of a plain stringMaksim Denisov
2025-01-07Store BackendDescription in StorageConfigMaksim Denisov
...instead of a plain hash. Hash gets computed for different storage types on the fly.
2025-01-07TargetCache: employ the shard even for a default constructed objectMaksim Denisov
...since this is a more generic approach.
2024-11-14tpp includes: Add hint for IWYU lintingPaul Cristian Sarbu
IWYU needs to be explicitly instructed how to handle included .tpp files in order to not falsely suggest their removal. Conversely, it also needs to know not to suggest including .tpp files instead of the corresponding .hpp files.
2024-11-14target_cache_key: Move hash definition to class headerPaul Cristian Sarbu
2024-10-07Enable misc-* checks.Maksim Denisov
2024-09-11Return ArtifactDigest from RepositoryConfig::RepositoryKeyMaksim Denisov
...to prevent additional conversions to ArtifactDigest from plain strings.
2024-08-27Reformat code to comply with clang-format 18Klaus Aehlig
... while keeping our .clang-format file.
2024-07-16TargetCache: Use StorageConfig instance for shardingPaul Cristian Sarbu
Instead of computing the shard based on the RemoteExecutionConfig singleton, use the already computed hash stored in the passed StorageConfig instance, which now needs to be set up separately if bootstrapping in order to avoid unwanted includes. Storing the backend description to CAS and corresponding audit checks now take place in main.
2024-07-05Call uplinking via UplinkerMaksim Denisov
... instead of static calls to GarbageCollector
2024-07-05Use StorageConfig with generation for initialization of Storage's generationsMaksim Denisov
...instead of std::filesystem::path. StorageConfig is extended to return paths of Storage's parts.
2024-07-05Move functionality from StorageConfig to related classes.Maksim Denisov
2024-07-05Use a separate constructor for sharded TargetCacheMaksim Denisov
2024-06-11Move creation of TargetCacheKey description to TargetCacheMaksim Denisov
...to use corresponding Storage for storing auxiliary information.
2024-03-19serve target: Fix sharding inconsistenciesPaul Cristian Sarbu
When running in single node, serve endpoint should not even consider sharding. Additionally, garbage collection uplinking should also take the shard into account. For this purpose, a TargetCache instance now remembers if it was explicitly sharded and passed that information to the GarbageCollector for uplinking.
2024-03-11target cache: Add type aware of bootstrappingPaul Cristian Sarbu
This is needed in order to pass the correctly instantiated TargetCache to AnalyseTarget even when bootstrapping 'just'.
2024-01-16Keep implied target-cache values aliveKlaus Aehlig
... by uplinking them appropriately.
2023-11-30Resolve inconsistencies in third-party headers include formatPaul Cristian Sarbu
2023-11-15TargetCache: add new member function WithShard(shard) that returns a new ↵Alberto Sartori
TargetCache... ...backed by the same CAS, but the FileStorage uses the given shard. This is particularly useful for the just-serve server implementation, since the sharding must be performed according to the client's request and not following the server configuration.
2023-04-26imports: Switch to Microsoft GSL implementationOliver Reiche
... with two minor code base changes compared to previous use of gsl-lite: - dag.hpp: ActionNode::Ptr and ArtifactNode::Ptr are not wrapped in gsl::not_null<> anymore, due to lack of support for wrapping std::unique_ptr<>. More specifically, the move constructor is missing, rendering it impossible to use std::vector<>::emplace_back(). - utils/cpp/gsl.hpp: New header file added to implement the macros ExpectsAudit() and EnsureAudit(), asserts running only in debug builds, which were available in gsl-lite but are missing in MS GSL.
2023-03-13Storage: Reworked storage and garbage collectionOliver Reiche
The improved GC implementation uses refactored storage classes instead of directly accessing "unknown" file paths. The required storage class refactoring is quite substantial and outlined in the following paragraphs. The module `buildtool/file_system` was extended by: - `ObjectCAS`: a plain CAS implementation for reading/writing blobs and computing digests for a given `ObjectType`. Depending on that type, files written to the file system may have different properties (e.g., the x-bit set) or the digest may be computed differently (e.g., tree digests in non-compatible mode). A new module `buildtool/storage` was introduced containing: - `LocalCAS`: provides a common interface for the "logical CAS", which internally combines three `ObjectCAS`s, one for each `ObjectType` (file, executable, tree). - `LocalAC`: implements the action cache, which needs the `LocalCAS` for storing cache values. - `TargetCache`: implements the high-level target cache, which also needs the `LocalCAS` for storing cache values. - `LocalStorage`: combines the storage classes `LocalCAS`, `LocalAC`, and `TargetCache`. Those are initialized with settings from `StorageConfig`, such as the build root base path or number of generations for the garbage collector. `LocalStorage` is templated with a Boolean parameter `kDoGlobalUplink`, which indicates that, on every read/write access, the garbage collector should be used for uplinking across all generations (global). - `GarbageCollector`: responsible for garbage collection and the global uplinking across all generations. To do so, it employs instances of `LocalStorage` with `kDoGlobalUplink` set to false, in order to avoid endless recursion. The actual (local) uplinking within two single generations is performed by the corresponding storage class (e.g., `TargetCache` implements uplinking of target cache entries between two target cache generations etc.). Thereby, the actual knowledge how data should be uplinked is implemented by the instance that is responsible for creating the data in the first place.