Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
...that is a container of Values mapped to Keys, and supports constant complexity search of a Value by a given Key
|
|
Time stamps in local time without explicit time zone are ambigious,
definitely at the end of daylight saving time. Moreover, even
if explicit time zones were given, it is still unconvenient to
correctly sort event expressed in different time zones. However,
with increased use of `just serve`, logs originating from different
machines become the norm. Therefore, normalize all time stamps to
UTC (and explicitly state that this is the time zone used).
|
|
|
|
|
|
|
|
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.
|
|
|