summaryrefslogtreecommitdiff
path: root/src/buildtool/storage/config.hpp
AgeCommit message (Collapse)Author
2025-03-24TmpDir: minor refactoringMaksim Denisov
2025-01-07Implement rebuilding of StorageConfigMaksim 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-07Pass BackendDescription to StorageConfig from the outsideMaksim Denisov
2025-01-07Pack BackendDescription to a classMaksim Denisov
...to let it be stored as an independent instance.
2024-12-19Fix cause of minor warningsOliver Reiche
2024-11-14storage: Implement IWYU suggestionsPaul Cristian Sarbu
2024-09-13Check compatibility in Storage based on the hash typeMaksim Denisov
2024-09-13Rename Compatibility class to ProtocolTraitsMaksim Denisov
...and move it to the common stage.
2024-09-09Replace ArtifactDigest::CreateMaksim Denisov
...with ArtifactDigestFactory::HashDataAs
2024-07-22Rename HashFunction methods and enumsMaksim Denisov
2024-07-22Convert HashFunction to a regular classMaksim Denisov
2024-07-22Store HashFunction in StorageConfigMaksim Denisov
2024-07-22Pass HashFunction to ArtifactDigest::CreateMaksim Denisov
2024-07-19Storage config: change layout to support several storage generationsKlaus Aehlig
2024-07-16StorageConfig: Store also the execution backend description idPaul Cristian Sarbu
...such that it will be available to the TargetCache for sharing. Also, GC does not require remote execution information, so the logic for this subcommand is moved earlier in main.
2024-07-05Convert StorageConfig to a general classMaksim Denisov
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-05Use StorageConfig functionality via Instance()Maksim Denisov
...to track changes during refactoring easier.
2024-07-05Move functionality from StorageConfig to related classes.Maksim Denisov
2024-07-05Remove ConfigData from StorageConfigMaksim Denisov
...since it is an extra class that overcomplicates the config class.
2024-04-17Compactification: Obtain generation cache directories for compatibility modes.Maksim Denisov
2024-03-26Add missing system includesPaul Cristian Sarbu
Main culprits: - std::size_t, std::nullptr_t, and NULL require <cstddef> - std::move and std::forward require <utility> - unordered maps and sets require respective includes - std::for_each and std::all_of require <algorithm>
2024-03-13Move storage-aware tmpdir creation to configKlaus Aehlig
... as the fs_utils have a lot more dependencies making them usable in less places. Moreover, this function also serves to shape the layout of the local build root and hence is more appropriately placed in the config anyway.
2024-03-11local build root layout: collect all ephemeral directoriesKlaus Aehlig
... under a common root in the youngest generation. This will allow a simple way of cleaning them up during garbage collection.
2023-11-30Resolve inconsistencies in third-party headers include formatPaul Cristian Sarbu
2023-07-05RemoteExecutionConfiguration: support dispatch listKlaus Aehlig
Extend the configuration data structure by a dispatch list of endpoints to chose based on the first match of the execution properties.
2023-05-23Storage config: also specify the location of the execution rootKlaus Aehlig
As local execution is tightly coupled to storage, also specify the layout in the storage configuration. In this way, we have a central place specifying the layout of just's cache directory and avoid accidentally getting into conflicting situations. While there, also move the execution root under the generation regime, to ensure that left-over execution directories (e.g., after a forceful termination of the program) eventually get cleaned up by garbage collection.
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-04-04Make git root part of the storage configKlaus Aehlig
In this way, we have the whole layout of the local build root consolidated in one place. Moreover, in this way, the location of the git root is also available to the build tool itself and can, e.g., be used as fallback CAS.
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.