| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
...to track changes during refactoring easier.
|
|
|
|
|
|
...since it is used for capturing in lambdas for AsyncMaps and mustn't be temporary.
|
|
...instead of std::optional<gsl::not_null<IExecutionApi const*>>
|
|
...and replace verbose constructions.
|
|
|
|
...instead of not_null const ptr.
|
|
|
|
...and adjust interfaces.
|
|
...instead of using singleton calls.
|
|
...to track changes during refactoring easier.
|
|
The gsl-lite implementation is slightly more picky in terms of
type conversions and constness resolution in initializers,
therefore small changes were needed.
|
|
The association map file for a resolved tree was supposed to
guarantee that the respective tree is kept alive in a Git
repository as part of a tagged commit.
This commit fixes this issue by tagging the tree (found in the Git
cache after resolution) before writing its association file.
|
|
In certain cases, e.g., on the serve endpoint, an unresolved tree
might lie in a repository other than the Git cache, therefore we
cannot create any new entries there, as it would violate our
guarantee that we only write under our local build root.
Therefore, the resolve_symlinks_map now receives pointers to both
the source and target Git databases and ensures that:
1. any tree created on-the-fly is stored exclusively in the target
repository, and
2. any other entry required for those trees is made available in
the target repository by copying it from the source repository.
Note that in our use case the target repository is always our Git
cache and passing a pointer to that object database is done to
avoid the overhead of otherwise opening the database very often.
|
|
|
|
If we set up the root for an archive repository as absent, we
should first check if the serve endpoint can set it up for us, and
only then try to provide it from locally available means.
|
|
Main culprits:
- std::size_t, std::nullptr_t, and NULL require <cstddef>
- std::move and std::forward require <utility>
- unordered maps and sets require respective includes
- std::for_each and std::all_of require <algorithm>
|
|
... as the fs_utils have a lot more dependencies making them usable
in less places. Moreover, this function also serves to shape the
layout of the local build root and hence is more appropriately
placed in the config anyway.
|
|
... instead of replacing the host name of each mirror, it
should only reorder the list of given mirrors.
|
|
... and ensure that paths starting with .// remain relative.
|
|
... by avoiding reusing temp dirs for execute. While we are
at it, also refactor LocalFetchViaTmpRepo() to create its
own empty temp dirs, that cannot be reused by the caller.
|
|
Asking the remote-exeuction endpoint for the tree means, that,
upon success, we fetch every archive from the remote execution
endpoint, even those that we could get from a provided distdir. As
our preference is to only use the network if necessary, simply use
the standard way of creating a distdir: create it locally and for
each file, try to get it from local resources first, then from the
remote-execution endpoint, and finally from other network resources.
|
|
... after handling absent roots. Otherwise, we violate the condition of
calling the setter precisely once.
|
|
|
|
In order to set up roots, just-mr is able to interrogate, if given,
serve and/or remote-execution endpoints. However, just-mr operates
only with Git hashes, i.e., with a native mode CAS.
This commit ensures the correct interactions occur between just-mr
and the provided endpoints not only in native mode, but also in
comaptible mode, where a serve endpoint might be present even if
one cannot make use of its associated remote-exection endpoint.
The user always gets informed if any incompatibilities are
detected.
|
|
This commit fixes the invariant that a file association between
a Git commit and the root tree should only be set if that tree is
found in our own Git cache. This ensures consistency between
present and absent roots and in the interaction with the serve
endpoint.
|
|
For archive repositories we need to ensure that a non-absent root
is backed by an archive content blob in the local CAS, in order to
also keep the proper root tree file associations. This change also
simplifies the content_cas_map logic by removing the previous
separation of implementation logic between fetching and setting up
the workspace root.
|
|
When fetching git repositories, just-mr routinely shells out to
git. In this case, allow the user to specify via "inherit env",
which environment variables from the host environment should be
made available in this action. Typical variables to inherit are
ones providing credentials, like SSH_AUTH_SOCK. As the repository
description specifies the commit that will be taken, and hence the
resulting tree, correctness is not affected by the environement
leaking in here.
|
|
At some point we have to decide if a given git repository URL is
a path. So far, we assumed that anything not starting with ssh://,
http://, or https:// is a path. This ignores the facts that
- the file:// scheme, while referring to a file, does not denote
a relative path starting file://,
- the [user@]host:path scheme is not a path on the local machine,
- there exist the URL schemes git://, ftp://, and ftps://, and
- future extension might add additional schemes.
To also correctly handle new schemes that git might add (which we
indeed can handle, as we simply shell out to the git binary), we
reverse the approach: we give the user the means to unambigiously
specify that they refer to a path on the local machine, by either
- using the file:// scheme,
- providing an absolute path starting with /, or
- providing a relative path starting with ./
All other schemes will not be modified. The file scheme, as well
as the git://, http://, and https:// scheme, are handled interally
using libgit2; all others are passed on to git in an unmodified form.
|
|
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
... instead of some hard-coded strings, as that can be confusing
when the tool is packaged under a different name.
|
|
If root is marked absent and we're not asked to fetch absent, we
can compute the resulting distdir root tree in-memory, as we have
all the information. Otherwise, i.e., if we actually need to have
the archives locally, we first check if the remote serve can
provide them in the remote CAS before continuing as before to fetch
the listed archives one at a time.
|
|
Now we look for the content blob also in the local Git cache, not
just in local CAS. If found, we store the blob read from Git cache
into local CAS and continue as usual.
|
