| Age | Commit message (Collapse) | Author |
|---|
|
This was causing the remote serve address to overwrite the one set
for remote execution.
Also, to keep things clean, some common remote server-related
methods and definitions were moved into their own library.
|
|
Just like the remote-execution protocol has several services (Execution,
ActionCache, ContentAddressableStorage, etc), so will the serve
protocol: the actual target-level caching, as well auxilliary
services, like the service to obtain the tree for a given root. Already
follow that scheme, before the protocol gets part of any release.
Also, move the status enum into the respective answer messages. In this
way, we can have different enums for different requests without causing
conflicts on the named enum constants.
|
|
server is started
|
|
The serve service will communicate with this endpoint when needed,
as well as ensure artifacts it provides are synced with the remote
execution CAS, if requested by the client.
If just-mr is given the --fetch-absent option, it Always produce
present roots irrespective of the 'absent' pragma. For Git repositories
marked with the 'absent' pragma, first try to fetch any commit
trees provided by the serve endpoint from the execution endpoint
CAS, before reverting to a network fetch.
Co-authored-by: Klaus Aehlig <klaus.aehlig@huawei.com>
Co-authored-by: Alberto Sartori <alberto.sartori@huawei.com>
|
|
This functionality will be needed to upload git trees
to a remote-execution end point by `just serve.
|
|
|
|
|
|
...able to request the tree of a commit known to the remote.
|
|
Initial version, to be extended later with other RPCs.
|
|
|
|
|
|
|
|
|
|
There is no need to use the full format API, so avoid increasing
the compile time gratuitously.
|
|
|
|
... in the human-readable description. More precisely, for
any implicit target field, show
- the field documentation given (if any), and
- the resolved targets this field contains.
However, do not show the actual name of the field, as this name
is internal to the rule and not part of the interface.
|
|
|
|
|
|
... to silence false-positive 'possible dangling reference'
warning produced by gcc 13.2.0.
|
|
... which are only actions that, besides giving exit code 0 also
created all the outputs they promised to.
|
|
|
|
... by moving the diagnose and cli related code into to separate
libraries. In this way, we hopefully improve maintainability of
the code base.
|
|
|
|
|
|
|
|
While a foldl is enough to implement a reverse functionality,
adding it as a built in allows doing so in linear time.
|
|
... to obtain from a list of strings a map with those entries
as keys and true as value. In this way, repeated membership tests
in lists can be implemented more efficiently.
|
|
|
|
|
|
... in order to make that functionality reusable
|
|
The rule generates a non-upwards symbolic link with given target
path.
|
|
|
|
If install-cas finds a file in the target location, unlink it before
writing (in the same way as install does already). In this way, we
avoid changing other file locations in the presence of hard links.
|
|
Upwards symlinks should still be collected from actions, even if
only the non-upwards symlinks are supported artifact types. The
client side is thus the one responsible with enforcing the
non-upwardness condition.
|
|
|
|
... to allow selecting a sub object of a specified tree.
|
|
|
|
|
|
Before this patch, when creating an action directory, symlinks were
staged as regular files.
|
|
|
|
The bytestream server implementation (deployed by just execute) now
stores the temporary files under
$local_build_root/protocol-depenedent/generation-0
so that they can be garbage collected if "just exectue" is terminated
before they are cleaned up.
|
|
...that std::filesystem::* calls produce. This is because existence
and type checks use almost exclusively std::filesystem::status,
which follows symbolic links, when being called with path arguments.
Instead, one should instead use these methods with the value
returned by a call of std::filesystem::symlink_status.
This commit also streamlines the FileSystemManager tests, as well
as replace bare calls to std::filesystem with their FileSystemManager
counterparts (where suitable).
|
|
The introduction of non-upwards symlinks as first-class objects
should have updated the handling of known git tree artifacts
containing symlinks. In particular, one should consider trees in
their entirety when uploading (irrespective of the ignore_special
flag), and git trees should only be reported as known only if
the ignore_special flag is set to false.
|
|
|
|
The command 'git add .' does not include paths found in .gitignore
files in the directory tree where the command is issued. This is
not the desired behaviour, as we expect for a tree with a given
commit id to contain all of the entries, irrespective of their
meaning to Git.
This commit addresses the issue as described.
For the just-mr.py script we modified the staging command to
'git add -f .'.
For the compiled just-mr, simply adding the force flag to
'git_index_add_all' did not work as intended for files found in
ignored subdirectories. This is a known libgit2 issue which has
been fixed in v1.6.3. Until we can upgrade our libgit2 version,
a workaround was implemented: we recursively read the directory
entries ourselves and add each of them iteratively using
'git_index_add_bypath', making sure to ignore the root '.git'
subtree (which cannot be staged).
At the moment the handling of Git submodules remains an open issue,
as Git does not allow '.git' subtrees to be forcefully added to the
index, and thus such directory entries will currently not be
considered as part of a git tree. This however is consistent
behavior between Git and libgit2.
|
|
...allowing the skipping of certain subtrees if needed. This is
useful, e.g., in simulating what a 'git add' call would do,
which ignores all '.git' subdirectories.
Also adds a corresponding test for the new method.
|
|
In this way, the user can specify which execution endpoint
to use depending on the execution properties.
|
|
|
|
Extend the configuration data structure by a dispatch list of endpoints
to chose based on the first match of the execution properties.
|
|
... in a way consistent with what we're using at other places
already.
|
