| Age | Commit message (Collapse) | Author |
|---|
|
...together with its dependencies:
- boringssl dec0d8f681348af8bb675e07bd89989665fca8bc
- protobuf v29.0
- abseil 20240722.0
Also update the bootstrap command for ssl to account for the fact
that now also the crypto library has fully moved to C++ and the
location of its sources has changed.
|
|
... verifying that indiections are correctly taken into account.
|
|
Originally, it was a good idea to add the full "bin" directory to
the bootstrap sources; all scripts there where used in some form
or another during bootstap and by taking the whole directory, we
wouldn't have to update the target when adding new scripts.
However, times have changed. The set of scripts neede for bootstrapping
is stable for quite a while now; on the other hand actively-developped
tools (like just-lock and just-import-git) now reside in "bin".
So, to avoid unnecessary runs of the bootstrap tests, prune the
dependency set.
While there, also mark as tainted.
|
|
When deciding if a repository is a computed root (i.e., of type
"computed" or "tree structure"), first follow indirections.
Otherwise we would try to read of the "type" entry of a string
which, of course, crashes.
Based on the similar fix for just-import-git.
|
|
When deciding if a repository is a computed root (i.e., of type
"computed" or "tree structure"), first follow indirections. Otherwise
we would try to read of the "type" entry of a string which, of
course, crashes.
|
|
|
|
Python's Global Interpreter Lock (GIL) hugely reduces the amount of
parallelism one can achieve. However, as cloning repositories is
I/O bound, the total runtime is improved by running it in parallel.
|
|
Python's Global Interpreter Lock (GIL) hugely reduces the amount of
parallelism one can achieve. However, as the checkout methods are
I/O bound, the total runtime is improved by running them in
parallel.
|
|
This will allow it to be run mostly asynchronously with other
checkouts in the future.
|
|
This will allow it to be run mostly asynchronously with other
checkouts in the future.
|
|
This will allow it to be run mostly asynchronously with other
checkouts in the future.
|
|
Similarly to how it is done in just-mr:
- lock against concurrent git-tag calls;
- extend git-fetch call with arguments that ensure thread-safe
operation.
|
|
|
|
...by first retrieving only the desired commit id from the
definitive remote in order to allow it to be checked against the
local Git cache. This massively reduces the average network traffic
from regenerating the just-mr configuration in justbuild projects
that always require the latest version of their dependencies.
|
|
|
|
|
|
|
|
Match correctly the behavior of just-mr, i.e., resolve the special
entries of the relevant subtree of the original tree instead of
taking the subtree of the resolved original tree. This also means
that the clones of archives can directly stage the relevant subdir
of the unpacked content and forward any 'special' pragma (same as
for other cloned repository types).
|
|
|
|
|
|
...in order to avoid copying while uploading.
|
|
|
|
|
|
|
|
...and remove an unused method.
|
|
|
|
...to remove code duplication.
|
|
|
|
|
|
|
|
|
|
...since ArtifactBlob rehashes data on construction and guarantees that the digest matches the content.
|
|
|
|
|
|
ArtifactBlob rehashes content, there's no way to construct it with a wrong digest.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... documenting the chanages since the first beta release. While there, also
fix the structure of the document and unify use of empty lines.
|
|
Reduce interference of invocation logging with regular logging
operations; in particular, restrict just-mr passing the --async-profile
option only to build commands and thus avoiding race conditions with
calls to `analyse` that rely on having a graph available immediate
after invocation.
|
|
To properly use `just serve`, both the client and the serve instance
must talk to the very same execution endpoint. Typically, both the
client and serve can reach out to the execution endpoint via the same
IP address. However, it might be possible that the client and a serve
instance know the same execution endpoint by means of differnet IP
addresses. For example, the client knows the execution endpoint
address through an _external_ IP address, while the serve instance,
deployed within the same network infrastructure, only knows the
_internal_ IP address.
This patch adds the subkey `"client address"` -- of the key
`"execution endpoint"` -- in the serve configuration file, to specify
the alternative pair `address:port` used by the client.
|
|
|
|
|
|
|
