| Age | Commit message (Collapse) | Author |
|---|
|
... instead of hard-coding it in the example graphs. In this way,
we can honor a provided PATH.
|
|
|
|
... to make tests pass also on systems where /bin/sh does not,
by default, pull in a path to "the standard tools".
|
|
... and only let test do the check on the final resulting boolean,
where the string representation is canonical. In this way, we avoid
having to rely on the string representation of numbers, where, e.g.,
1 and 1.0 are equally valid representations of the same number.
|
|
... in the local launcher for the execution end point. In this way,
the tests also work on systems where sh does not pull in enough
paths to have all the "usual" tools available.
To also get a correct path on systems relying on sh pulling in
enough paths, take what sh, launched with the default launcher,
would believe the path is.
|
|
... for test actions, by setting an appropriate local launcher. In
this way, the tests can also be run on systems where sh does not
pull in enough paths to have all the "usual" tools available.
|
|
As we patch that API, it also can implicitly depend on the
toolchain (and hence its config), if we use a compiled implementation
of patch. Making the TOOLCHAIN_CONFIG a flexible part of the config
allow to, again, build static binaries as usual.
|
|
|
|
... as, for absent repositories, we need to get the description from
the serve end point. As a consequence, also support -r and --compatible,
as the remote-execution endpoint needs to fit with the one for the
serve endpoint.
|
|
... as even this command now adds entries to CAS, e.g., the shard
for the target-level cache. Also, this command block gc by keeping
a lock (also in the local build root).
|
|
Also cleans up the logging when parsing the serve service
configuration file.
|
|
As the serve service always has an associated remote-execution
endpoint, when just-mr gets passed only a serve endpoint address it
will now default to implying a remote-execution endpoint exists too
at that address. Additionally, now the implementation of the
--backup-to-remote option more clearly shows that it can only be
done in native mode.
|
|
The requests to retrieve the tree of a commit, archive, or distdir
also set up those trees in a way that the serve endpoint can later
build against them, besides allowing just-mr to set up roots
locally. Therefore, if the witnessing entity (Git commit, content
blob, or distdir, respectively) is known to the serve endpoint,
then failing to set up the root tree there should result in a
failure also of the just-mr setup on the client side.
|
|
For archives and Git repositories we should ensure that not finding
the witnessing entity (archive content blob or Git commit,
respectively) results in a distinct status in the response to a
request that sets up roots on the serve endpoint. This will allow
just-mr to better handle its interaction with the serve endpoint.
|
|
A change made to this test was wrongly setting the same path both
as build root for the serve instance and for the just-mr instances
being tested, resulting in the build root of the serve instance
being inadvertently removed during the test. This commit fixes the
issue by giving the serve endpoint its own build root path.
|
|
|
|
While just-mr does not use remote-execution properties, it is
still useful to have those as a separate entry in the rc file. With
rc-file delegation, this gives committed rc files an easy way to
specify the image to be used without having to set all the remaining
arguments for the various just subcommands in "just args".
|
|
|
|
|
|
|
|
|
|
... to pull in rc files from different locations, given by
location objects.
|
|
|
|
... to allow, in a clean way, add computing the effective rc
by overlaying delegated rc files.
|
|
Adds documentation for the new proto requests required for the
'to_git' pragma root handling, as well as general syncing of root
trees. Also adds clarifying comments on handling of absent roots by
just-mr.
|
|
|
|
To take advantage of absent roots, we need to ensure that a given
serve endpoint can build against the tree of this generated root.
For a 'distdir' repository we can know the resulting tree
identifier directly without actually needing to fetch anything.
Therefore, we only set the root as absent if the serve endpoint
knows already this tree, if it can set it up itself, or if
we can provide this tree to the serve endpoint from one of our
CAS locations (local or remote), based on our tree invariant
guarantee. A network fetch of the archives never gets performed
for an absent root.
If a serve endpoint is not provided, an absent root can still be
generated, but only if no network fetches are required. In this
case a warning is emitted.
|
|
To take advantage of absent roots, we need to ensure that a given
serve endpoint can build against the tree of this generated root.
To this end, for an 'archive' repository we only set the root as
absent if the serve endpoint knows already the root, it can set it
up itself, or we can create the root locally without a network
fetch and then upload it to the serve endpoint via the remote CAS.
A network fetch never gets performed for an absent root.
If a serve endpoint is not provided, an absent root can still be
generated, but only if no network fetches are required. In this
case a warning is emitted.
|
|
...by passing around the AsyncMap key struct instead of individual
members. This will also make future code changes more easy to
implement and improve code readability.
|
|
To take advantage of absent roots, we need to ensure that a given
serve endpoint can build against the tree of this generated root.
To this end, for a 'git' repository we only set the root as absent
if the serve endpoint knows already the root, it can set it up
itself, or we can create the root locally without a network fetch
and then upload it to the serve endpoint via the remote CAS.
A network fetch never gets performed for an absent root.
If a serve endpoint is not provided, an absent root can still be
generated, but only if no network fetches are required. In this
case a warning is emitted.
|
|
To take advantage of absent roots, we need to ensure that a given
serve endpoint can build against the tree of this generated root.
To this end, for a 'git tree' repository we only set the root as
absent only if the given serve endpoint has this root, or the tree
is known locally and can be provided via the remote CAS. While
generating an absent root the fetch command will never be called.
Generating an absent root without being provided a serve endpoint
is still allowed, but results in a warning.
|
|
|
|
Marking a file-type repository as 'to_git' results in a Git-tree
type root, which are of course content fixed and can be (and
usually are) used by export targets. Therefore, it is beneficial
for a serve endpoint, if one is provided, to be aware of such a
root and be able to build against it if needed. If the root is
marked as absent, this condition becomes mandatory.
Generating an absent Git-tree root without being provided a serve
endpoint is still allowed, but results in a warning.
|
|
|
|
pragma-related RPCs
|
|
|
|
|
|
The purpose of the requests for the tree of an archive, commit, or
distdir also includes making those trees available for future
builds on the serve endpoint, which currently means being in a
known Git repository.
This commit ensures the distdir tree reqeust also includes the
import of the resulting tree from CAS into the Git cache (if the
tree is not already in a Git repsoitory).
|
|
This is to uphold the coding style guide we employ.
|
|
tree
When the remote CAS provides the root tree, we perform an
import-to-git operation, therefore the correct witnessing
repository for the tree should always be the Git cache.
|
|
...for more easily readable and maintainable target descriptions.
|
|
|
|
... regardless of the names chosen during packaging.
|
|
... instead of some hard-coded strings, as that can be confusing
when the tool is packaged under a different name.
|
|
...in accordance to our coding style.
|
|
|
|
|
|
... which were only honored when doing fetch and setup.
|
|
|
|
|
