Age | Commit message (Collapse) | Author |
|
|
|
|
|
...to track changes during refactoring easier.
|
|
Use a builder pattern for creation and validation, in a manner that
allows also other authentication methods to be added in the future
besides the current TLS/SSL.
The main Auth instances are built early and then passed by not_null
const pointers, to avoid passing temporaries, replacing the previous
Auth::TLS instances passed by simple nullable const pointers. Where
needed, these passed Auth instances are also stored, by const ref.
Tests also build Auth instances as needed, either with the default
'no certification' or from the test environment arguments.
|
|
|
|
|
|
...to more easily keep track of changes during refactoring.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
...instead of std::optional<gsl::not_null<RepositoryConfig const*>>.
|
|
...instead of std::optional<gsl::not_null<IExecutionApi const*>>
|
|
Most built-in rules are just described by their name, assuming they
are known to the user anyway. One exception, however, are "export"
targets, as those serve as interfaces to (logical) repositories and
hence is supposed to have a documentation of the target itself. Over
time, however, "configure" targets have evolved to become internal
interfaces (maybe even for an external target), e.g., to provide
default values and hence make better use of the actual export target.
Therefore it is desirable to provide a bit more information when
asked to describe a "configure" target.
- As "configure" targets have a fixed set of keys, adding a "doc"
field is a conservative extension; this can be useful to give an
overview what the target is about.
- An important information of a "configure" target is the target
that is configured. While this, in general, is an expression, in
the typical cases, the description is very short (a literal target
name, or a variable). So we can afford to show the definition.
|
|
...and replace verbose constructions.
|
|
...instead of not_null const ptr.
|
|
|
|
|
|
|
|
|
|
...and adjust interfaces.
|
|
...instead of intialization of the singleton.
|
|
...and adjust interfaces.
|
|
...instead of using singleton calls.
|
|
...instead of using singleton calls.
|
|
|
|
...to track changes during refactoring easier.
|
|
... and thus allowing proper quoting of command output.
|
|
...to enable validation of received blobs.
|
|
|
|
... but not all. Also in this case, if an target-level cache
entry is written, the dependencies have to be written as well.
|
|
Update logic populating containers to use the new method which
is aware of the maximum transfer limit.
|
|
... to allow generating symlinks as part of a rule, as it is already described
in our documentation.
|
|
...which do not stage also the debug source and header files (while
in debug mode), as this is unnecessary bloat in the tests.
As the tool-under-test and mr-tool-under-test targets should be
used instead of the regular install targets also in the various
extra rules in end-to-end and utils, move their definition in the
outmost test TARGETS file.
|
|
|
|
...to reduce the "price" of copying.
|
|
...instead of BazelBlobContainer to not bring bazel_re::Digest to IExecutionApi.
|
|
|
|
...where the template parameter is the type of a digest.
|
|
...instead of various iterators.
|
|
|
|
|
|
|
|
...REMOTE_EXECUTION_PROPERTIES env variable.
|
|
...instead of the unused ';'
Using spaces allows for simpler looping in shell script
|
|
...that come with installing just. This ensures control on the
subdirectories available to the runner, avoiding any possible
conflicting paths.
|
|
Compared to the command line, the environment usually is quite
short. So including it in messages reporting about commands does
not introduce a lot of additional noise. However, knowing the
environment can help understanding an error message. Therefore, it
seems a good trade off to include it. Do so.
|
|
The gsl-lite implementation is slightly more picky in terms of
type conversions and constness resolution in initializers,
therefore small changes were needed.
|