| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Print what we set to, not what was set before us. This enables us to
test that `spawn` mode is really enabled by looking at output from the
tests.
|
|
|
|
|
| |
It seems we don't need this anymore, thanks to cleaning up gRPC
background threads.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A fix was made in
https://gitlab.com/BuildStream/buildstream/merge_requests/1244
in order to set xdg_* env variables inside of the test's directory
to avoid importing data from the host.
There was however still two problems:
- When a variable was not set, it was set with a relative path, which
would create a configuration for BuildStream that is invalid.
- When a variable was set and running with pytest directly, we would
still use the variable's value, which would be the host one.
This ensure this can never happen, by not relying on the same variable's
name and always overriding them.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This fixes a bug where third party plugins cannot get tested
automatically because they are not part of BuildStream.
|
|
|
|
|
| |
This allows us to remove the platform reset helpers in
tests/conftest.py.
|
| |
|
|
|
|
|
|
| |
The cli_integration fixture provided in testing.runcli depends on the
integration cache fixture. This was missed when cli_integration was
originally exposed.
|
|
|
|
|
|
|
|
|
| |
- Rename plugintestutils to testing.
- Don't run the tests from bst-plugins-template. This imports
buildstream.plugintestutils so will have to be disabled to get
through CI. This can be re nabled once bst-plugins-template has been
patched.
|
| |
|
|
|
|
| |
https://gitlab.com/BuildStream/buildstream/issues/629
|
|
|
|
|
|
|
|
| |
Unlike the --integration option that activates additional tests marked
with 'integration', this new --remote-execution option deactivates all the
tests except those marked with 'remoteexecution'.
https://gitlab.com/BuildStream/buildstream/issues/629
|
|
Pytest implicitly loads this file from the CWD where it runs,
which is usually the project toplevel directory, but also supports
loading it from the `tests/` subdirectory where tests are run from.
Placing it into the `tests/` subdirectory is not perfectly explicit,
but is at least a hint to the unsuspecting developer that this file
is related to tests.
|