| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... that was implicitly fixed fb365b17ca339a25688ff61918280a46d64943b9.
|
|
|
|
Add a test that verifies that garbage collection does not violate
the invariants required by the extensional project implicit in
target-level caching.
|
|
... by uplinking them appropriately.
|
|
|
|
... that are eligible for caching. In this way, we can accurately keep
track of the dependencies between target-level cache entries. Note
that it is enough to track the export targets eligible for caching,
as no target depending on an ineligible export target can be eligible.
|
|
|
|
The implicit extensional projection of target-level caching and
garbage collection interact in a subtile way. Add a design document
describing how we keep the invariant required by target-level
caching in the presence of garbage collection. While, techincally,
this just describes how to fix a bug, a careful design is still
needed, as some fundamental changes are made.
|
|
Certain end-to-end tests require custom services. While normally
they come up in quickly (less than 2 seconds), on heavily overloaded
machines it might take longer. So increase the amount of time
these tests are willing to wait for the binary to start up to avoid
flakyness in our CI runs.
|
|
Our fetch and launch tool is parametric in the tool to be launched.
Reflect this in the documentation and do not pretend it to be the
name "just" hard coded. While there, also fix the hard-coded name
"git" in the documentation of the default value.
|
|
|
|
|
