b68209b6d4
During a deploy operation, we would fetch commit objects from the remote to resolve the version string. If gpg-verify was turned on, we would fail to pull them if some of the commits were not signed. This is because we pulled them in batches. We partially address this by only fetching the HEAD commit on the first pass. This allows `upgrade` operations to work just as well as `deploy` operations. Though there is still an issue if we have to traverse farther back than when signed commits become unsigned (unless they happen to fall on a batch boundary). We leave that unsolved for now, since that would likely require a more complex solution and it's not clear whether it's a real world issue (signers can just retroactively sign commits). Copy the gpghome from ostree so that we can test GPG-related cases in our suite. Closes: #527 Closes: #557 Approved by: cgwalters |
||
|---|---|---|
| .. | ||
| check | ||
| common | ||
| compose-tests | ||
| composedata | ||
| gpghome | ||
| manual | ||
| utils | ||
| vmcheck | ||
| compose | ||
| 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.