88ffdc0ae2
This currently requires a `--i-know-this-is-experimental` flag; I know it'd be a bit more consistent to have it under `ex`, but what feels weird about that is *most* of the `ex` commands people use are client side. This is where we want it to ultimately end up. We've landed a lot of prep patches, but I know there's still a notable amount of code duplication with `compose tree`. What's left is about ~700 lines but it's mostly not hard/complex code anymore. In the future, I'd like to extract more of the compose code to a `rust/src/compose.rs` or so, but I think this is sustainable fow now. My high level goal is to get this into coreos-assembler and stand up a Silverblue build that uses it. Closes: #1512 Approved by: jlebon |
||
|---|---|---|
| .. | ||
| check | ||
| common | ||
| compose-tests | ||
| composedata | ||
| ex-container-tests | ||
| gpghome | ||
| manual | ||
| utils | ||
| vmcheck | ||
| compose | ||
| ex-container | ||
| README.md | ||
Tests are divided into three groups:
-
Tests in the
checkdirectory are non-destructive and uninstalled. Some of the tests require root privileges. Usemake checkto run these. -
The
composechecktests currently require uid 0 capabilities - the default in Docker, or you can run them via a user namespace. They are non-destructive, but are installed.To use them, you might do a
make && sudo make installinside a Docker container.Then invoke
./tests/compose. Alternatively of course, you can simply run the tests on a host system or in an existing container, without doing a build.Note: This is intentionally not a
Makefiletarget because it doesn't require building and doesn't use uninstalled binaries. -
Tests in the
vmcheckdirectory are oriented around using Vagrant. Usemake vmcheckto run them. See alsoHACKING.mdin the top directory.
The common directory contains files used by multiple
tests. The utils directory contains helper utilities
required to run the tests.