| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Normally, actions are supposed to work silently, i.e., without writing
to stdout/stderr. So, if an action produces console output, it is
definitely worth looking at, even for cached actions. Therefore,
add a section after the failed actions showing those actions (if
not in the previous action). Also, always show duration (if known)
and if an action is cached (which can happen for the ones producing
console output).
|
|
By supporting test matrix top-level of our test, which
affects both the ALL and the UNIT_TESTS target, it is
easy to run all tests for different tool chains, flags,
or CC_TEST_LAUNCHER values.
|
|
When using a serve endpoint, analysis errors my contain a reference to
a build failure on serve, shown as 'blob <hash>'. For each such blob
reference add a link offering to read this blob.
|
|
Currently the support hashes are SHA-1 (for git hashes), which has 160 bits and
SHA-256 which has 256 bits. Therefore, we expect either 40 or 64 hex digits.
|
|
|
|
... to make sure it is run in native and compatible mode.
|
|
|
|
... instead of the full out_dir path, which is not
guaranteed by the RBE protocol.
|
|
|
|
... which requires all entries to be sorted in
lexicographical order.
|
|
... by ignoring it rather than trying to dereference a nullptr.
|
|
|
|
Often it is desirable to run tests in a variety of configurations:
different toolchain used, different target architecture, different
protocol versions in end-to-end tests, etc. The rule ["test", "matrix"]
allows running tests in those exponentially many combinations in
a single target and thus makes full test coverage maintainable.
|
|
|
|
|
|
While there, sort filter URLs
|
|
|
|
to 100
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The directory name is designed to allow an easy rough sorting by
time. This can also be used to identify the latest build for a
specific user. However, users often run several builds in a single
minute; therefore, increase time-stamp precission to include
seconds as well. While still lexicographic and chronological order
will disagree, at least for a single user it will be correct most
of the times.
|
|
When looking at an invocation, it can be helpful to quickly get
all other invocation that coincide with a specific remote-execution
property (like the build image). Support this use case by adding
appropriate filtering and links.
|
|
It allows to specify a list of environment variables, which are captured at
invocation time and stored as key-value pairs in the metadata file. This allows
to get some information about the invocation context such as username,
merge-request ID or source branch (on a CI runner), or others.
|
|
|
|
|
|
|
|
While activating DEBUG requires setting it to a non-empty map,
providing information on whether and how debugg fission should be
used, we should still allow any logically false value (rather than
just null) to disable a debug build in order to make it easier for
the user to explicitly disable debugging.
Also adopt and fix the documentation strings.
|
|
While there, also make sure we run unit tests that honor
TEST_COMPATIBLE_REMOTE in both configurations.
|
|
|
|
|
|
Include in the profile also the effective remote-execution endpoint,
properties, and dispatch list. Software projects are often tested
in a variety of environments or hardware configurations; as,
obviously, the performance might differ significantly (especially
depending on the used hardware) a proper analysis therefore requires
the possibility to distinguish the various backends. Adding the
effective configuration adds this posibility.
|
|
|
|
... in the summary, so that the user knows what to expect when
looking into the details-environment.
|
|
|
|
So far, the configuration variable TEST_BOOTSTRAP_JUST_MR could be
used to decide whether to run the end-to-end tests with the compiled
version of just-mr or the python script, which is mainly used for
bootstrapping only. To have a more simple way of running all tests in
all relevant configurations, make this an internal variable and branch
on the possible values, similarly as we already do for the possible
values of TEST_COMPATIBLE_REMOTE.
|
|
As a configure target, it is supposed to describe the change in the configuration;
setting a parameter to itself has no effect.
|
|
With the introduction of new exit codes, the presentation of
an invocation was changed to refrain from showing actions in
abnormal case failure already during analysis phase. However
ca8fd841736ca65fa4292887052c78243512962a did not include the case of
a successful build into the cases of normal circumstances. Fix this.
|
|
|
|
|
|
|
|
|
|
|
|
... by the requested subcommand. In particular, do not set it for
pure analyse requests.
|
