| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
| |
We continue to support the jvm property -Dbazel.DigestFunction, for backwards compatibility, but this will go away. The startup-option is marked experimental for now as we iron out issues. (note: leaving this out of release notes until the experimental tag is removed)
As part of this refactor, the default constructor calls for FileSystem and derived classes will now use this default. This should remove the need for constructors that accept custom hash functions.
RELNOTES: None.
PiperOrigin-RevId: 207035217
|
| |
|
|
|
|
|
|
|
| |
enum.
Now that we aren't using enum names for the hash functions, we also accept the standard names, such as SHA-256.
RELNOTES: None.
PiperOrigin-RevId: 201624286
|
| |
|
|
|
|
|
| |
RELNOTES: Bazel's default hash function was changed from MD5 to SHA256.
In particular, this affects users of remote caching and execution, as
all hashes will be SHA256 by default.
PiperOrigin-RevId: 177740702
|
|
|
Refactor the FileSystem class to include the hash function as an
instance field. This allows us to have a different hash function
per FileSystem and removes technical debt, as currently that's
somewhat accomplished by a horrible hack that has a static method
to set the hash function for all FileSystem instances.
The FileSystem's default hash function remains MD5.
RELNOTES: None
PiperOrigin-RevId: 177479772
|
ccalvarin
buchgr