| Age | Commit message (Collapse) | Author |
|---|
|
|
|
To avoid lock contention, our task system queues tasks in several
queues. In order to know when there is no more work to be done, a
global counter keeps track of the total work. Here, it is important
that this counter be incremented before a value is added to the
queue, for otherwise some other thread could pick it up and decrement
the total work load, hence getting us in a state where the counter
underestimates the total amount of work to be done. Fix the order
of those operations.
|
|
The result of the analysis is a JSON object containing the keys
`"artifacts"`, `"runfiles"`, and `"provides"`. This JSON object, by
default, is logged. However, it might be useful to process the data
contained in it, while, for example, developing new rules.
This patch adds a new command line option (`--dump-result`), reserved
to the subcommand `analyse`, to dump the analysis result to the given
file or stdout (if `-` is given).
|
|
|
|
Before this patch, if the option `--remote-execution-property KEY:VAL`
is repeated multiple times (also with different `KEY`s), only the last
one is taken into account.
This patch fixes the intended behavior.
|
|
To avoid too many intermediate results, we compute the union of
a list in a divide and conquer fashion. Of course, for a disjoint
union, the recursive calls on the lists of half the length have to
be disjoint as well, i.e., the template parameter kDisjoint has to
be passed on. Fix this.
|
|
|
|
... to clean up what can be done without losing cache information.
|
|
|
|
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.
|
|
... to pull in rc files from different locations, given by
location objects.
|
|
|
|
... that was implicitly fixed fb365b17ca339a25688ff61918280a46d64943b9.
|
|
|
|
|
|
The ToJson method of RemoteAddress was wrongly creating a list
instead of a simple string, thus a wrongly formatted backend
description was being used to shard the target cache. This however
does not affect the correctness of the build.
Changelog also updated accordingly.
|
|
... and improve log messages in case of failure.
|
|
|
|
|
|
The install target, like any other target, has to have artifacts
and runfiles being proper stages, i.e., in such a way that the
keys can be interpreted as names in the file system without causing
conflicts. This property used to be unchecked, thus allowing users
to define mal-formed targets that, when used as inputs to actions,
would result in unspecified layout of the action directory. Fix
this by adding an appropriate check enforcing well-formedness of
the resulting stage.
|
|
... clarifying the effect of the target-cache-key change. In
particular, explain that, as the cache-key format has changed
in a non-overlapping way, no care has to be taken on update, but
old target-cache entries will not be used by the newer version
of the tool.
While there, fix some typos and properly break lines.
|
|
... ensuring that just-mr passes on the specified environment
variables (and only those) to the tree-generating action.
|
|
The cache key for an export target should contain as target name
that of the export target (and its effective configuration) rather
than the exported target. As we computed the repository part of
the cache key for the target included in the key, this was still a
correct cache key except in the case an explicit file reference was
exported (as here, the information that the file was to be taken
rather than the target of the same name got lost). We still fix
this issue by making the implementation match our design (rather
than by including the file-reference bit in the cache key), as the
original design gives the cleaner protocol for target-level caching
as a service.
|
|
...of the internal cache used for keeping track of running operations.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... to pass along toolchain settings for current and future
toolchain definitions. Configuration variable
COMPILER_FAMILY is replaced by TOOLCHAIN_CONFIG["FAMILY"].
|
|
|
|
|
|
If install-cas finds a file in the target location, unlink it before
writing (in the same way as install does already). In this way, we
avoid changing other file locations in the presence of hard links.
|
|
|
|
The bytestream server implementation (deployed by just execute) now
stores the temporary files under
$local_build_root/protocol-depenedent/generation-0
so that they can be garbage collected if "just exectue" is terminated
before they are cleaned up.
|
|
|
|
In this way, the user can specify which execution endpoint
to use depending on the execution properties.
|
|
... so that any left-over directories, in case of abnormal termination
are cleaned up eventually.
|
|
|
|
|
|
|
|
|
|
As local execution is tightly coupled to storage, also specify the
layout in the storage configuration. In this way, we have a central
place specifying the layout of just's cache directory and avoid
accidentally getting into conflicting situations. While there, also
move the execution root under the generation regime, to ensure that
left-over execution directories (e.g., after a forceful termination
of the program) eventually get cleaned up by garbage collection.
|
|
Add an option --plain pretending that the remote repository
configuration is the canonical single-repository one. In this way,
repositories not having a multi-repository configuration (e.g.,
code built with a foreign build system) can be imported in the same
way to a template, thus providing a more uniform interface. This
can also be useful, if a repository is to be imported completely
without its transitive dependencis.
|
|
|
|
|
|
|
|
|
|
... asking just to transfer everyting installed to the local CAS first.
|
