| Age | Commit message (Collapse) | Author |
|---|
|
When running in single node, serve endpoint should not even
consider sharding. Additionally, garbage collection uplinking
should also take the shard into account. For this purpose, a
TargetCache instance now remembers if it was explicitly sharded and
passed that information to the GarbageCollector for uplinking.
|
|
|
|
...by increasing granularity in client-side reporting. This allows
to correctly continue with builds of local targets if the serve
endpoint does not have the requested target, as well as improve
the reporting for users on failure.
|
|
When the serve endpoint has all the information to analyse a
target, any analysis or build errors should be made available to
the client. This way the user can receive a relevant error report.
|
|
|
|
...by allowing a Logger instance to be provided. Also adds a flag
in order for failed artifacts from builds orchestrated by the serve
endpoint to be able to be reported as errors instead of warnings.
|
|
|
|
...by allowing a Logger instance to be provided.
|
|
...by allowing a Logger instance to be provided.
|
|
This allows to be explicit and thus have better control on where
messages get logged.
|
|
|
|
...as it is redundant here and exception prone.
|
|
...in the tool proper, i.e., excepting tests.
|
|
Some of the more specific issues addressed:
- missing log_level target/include
- header-only libs wrongly marking deps as private
- missing/misplaced gsl includes
|
|
... so that any updates of the local-build-root layout are correctly
taken into account. In particular, this change also moves the temporary
directory under the emphemeral root, allowing more quick clean up.
Co-authored-by: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com>
|
|
Commit 2ebf355989eb92ac9967eceee0af14d39477afe0 moved the tmpdir
creation for various tasks into the task itself. In doing so, TmpDir
was called with a relative path; that was, however, is interpreted
relative to the working directory, violating the property that
our tool never write anything outside the local build root unless
explicitly asked to do so (by specifying the output path in an
install or install-cas invocation). Fix this, by calling the the
tmp-dir function that is storage-layout aware.
|
|
... 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.
|
|
|
|
... as it is already encoded to be meaningfully printable.
|
|
... with effective config instead of the actual cache key, which
is simply a blob identifier that is probably not so meaningful for
the user watching the build.
|
|
... instead of blindly assuming the evaluation succeeds.
Co-authord-by: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com>
|
|
During analysis it is useful to track and report the progress for
all export targets. This is not exclusively linked to a serve
endpoint being present, despite most of the time being expected to
be spent in export targets being served from the remote endpoint.
This commit refactors the current implementation to give proper
feedback to the user on the progress of the analysis phase.
|
|
...when orchestrating a build.
|
|
|
|
...with regular instances that have controlled life-times.
This avoids race conditions in tracking and reporting the results
of analysis and build, as the serve endpoint can orchestrate
multiple builds at the same time asynchronously. As a bonus
side-effect this also ensures the correctness of the progress
reporting per orchestrated build.
|
|
The serve endpoint always has to access the correctly sharded
target cache, including during analysis. For this purpose, the
target cache instance interrogated during analysis has to be
explicitly provided.
|
|
This is needed in order to pass the correctly instantiated
TargetCache to AnalyseTarget even when bootstrapping 'just'.
|
|
... to clean up what can be done without losing cache information.
|
|
... and make rotation of generations optional, as with the removal
of ephemeral data there is now a useful collection even without
rotating generations.
|
|
... under a common root in the youngest generation. This will allow
a simple way of cleaning them up during garbage collection.
|
|
|
|
... 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.
|
|
|
|
... and prohibit moves and move assignments.
|
|
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.
|
|
We deliberately have many functions that do not abort the process
on failure and instead simply return a corresponding value. It
is then up to the caller to decide how to handle this failure;
in particular, such a failure can be expected, e.g., if we try to
fetch a file from remote execution first, before fetching it from
the upstream location.
To have a consistent user experience, nothing that can occur in
a successfull build should be reported at error level; moreover,
messages that routinely occur during successfull builds should not
be reported at progress or above, except for the (stage) result
messages and the progress reporter.
|
|
|
|
|
|
It is better to avoid empty catches when we have a reasonable way
to log an (even unlikely) exception, even more so if memory
allocations are involved.
|
|
|
|
|
|
...also for 'analyse' and 'describe'.
|
|
As these subcommands can access the serve endpoint, it is not
enough anymore to just know the remote-execution endpoint, but one
must also try to connect to it. Thus, the client-side
authentication arguments need to be supported and read.
The just.1 man page is also updated accordingly.
|
|
When just serve has to create a distdir from files known to it,
there are two kind of hashes involved.
- The requests, as well as the resulting tree always refer to git
identifiers.
- Additionally, files can be stored in the local CAS of the serve
instance. This CAS might use a different hash, e.g., plain sha256.
Therefore, we cannot simply forward the hash from the request to
a lookup in our local CAS; fortunately, when we add a file to the
local CAS, we are told the value of the applicable hash, represented
as bazel digest, hence we can simply remember essentially this
value (converting it to unprefixed form when running in native
mode, as in the following we need the hash as it is part of an
artifact digest).
|
