Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
As opposed to the regular CAS/cache, for the git repository implicit
in the repository cache we cannot guarantee that data from older
generation is always promoted via hard links. Therefore, a certain
amount of data can be duplicated between the repo-cache generations.
In order to allow compacting storage to the minimum, add an option
to gc-repo to only remove the older generation, without rotating.
|
|
Add support for repository gargabe collection to only drop the older
generations without rotating.
|
|
|
|
|
|
|
|
|
|
As only a recent commit made it possible to rotate the repository
cache more than once, add a test ensuring two properties.
- Repeated repository gc is possible and roots are taken from the
rotated generation.
- It is possible to fully rotate a root out.
|
|
While there, also check for availability first, to avoid duplicated
error messages (from git_cas and the caller).
|
|
...before trying remotes.
|
|
While there, improve docstrings of methods operating on Git
repositories to specify when the underlying Git repositories are
expected to be present.
|
|
Based on f0473730 and 22ef0a16
|
|
Based on 76ce2123
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When garbage collecting the oldest generation, we expect it to be
a non-empty directory. Therefore, remove it recursively.
|
|
While reporting an origin target with action number within that
target describes an action uniquely in a way meaningful to the
user, it might not always be eay to unserstand which precise action
is currently running. For example, for a library with many source
files, we have a target generating a large number of actions and
the association of source file to action number requires detailled
knowledge of the build description. The name of the primary ouput
of that action, on the other hand immediately identifies the file
that is compiled. Therefore, report this as well.
|
|
|
|
... and use it when normalizing the origins of actions. For this
task, any well-defined linear order is sufficient. Using a native
comparision (rather than comparing the canonical serialisation)
significantly speeds up that normalisation process, as the assumption
that it would be rare that an action has more than one origin turned
out to be false. In fact, we have seeen cases where this sorting
used to take several seconds before this change, so that this change
reduced analysis time by more than a factor of 5.
|
|
While our tool promises to generate a reproducible order of the
action origins, we should not insist on a particular one. Therefore
sort before comparing.
|
|
|
|
The "generic" rules deliberately resolves conflicts on identical
paths in a latest-wins fashion (seeing all artifacts as later than
all runfiles) to allow an easy way to define actions. However, the
inputs stage obtained by this resolution can still contain conflicts
and those are an error. Properly detect those. Also clarify in the
documentation, that only conflicts on identical paths are resolved
in the described priority, not semantic overlap.
|
|
|
|
|
|
|
|
|
|
|
|
... and replace it with a direct call to serve.
|
|
|
|
... and replace it with a direct call to serve.
|
|
...since it is superseded by ServeApi's method.
|
|
|
|
...instead of EnsureAbsentRootOnServe.
|
|
|
|
...instead of EnsureAbsentRootOnServe.
And remove unused arguments.
|
|
|
|
...instead of EnsureAbsentRootOnServe.
|
|
|
|
...instead of EnsureAbsentRootOnServe
|
|
|
|
|
|
|
|
... rather than as future design. While there, also add target-level
caching as a service to the list of documentation pages.
|
|
Trying to access a git object return a recoverable failure, hence
the failure to find the object in the git object database should
be logged at warning level at most. Moreover, in some cases we
should log that event at an even lower level, e.g., if we're just
checking the presence of the object in the local git cas to avoid
unnecessary network access.
|