27bd7b97bb
There are a few scenarios today where one might deliver content to a machine via an external transport. For example, take the scenario of a single server updated via USB drive. While we can provide a refspec...what should the remote be? (This gets into ostree collections). There's nothing really that can happen when typing `rpm-ostree upgrade` unless the USB stick is plugged in. That type of scenario should be emphasized by pinning the commit - the machine is updated via an external script. Another case: we're experimenting embedding OSTree commits inside OCI containers. Here again since rpm-ostree can't understand how to pull content from containers, it's saner to drop the refspec bits, and pin to a commit. Further enhancements will follow to make the admin experience more obvious. Closes: #1396 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.