keremet/rpm-ostree
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
5879b96a64
rpm-ostree/tests
History
Colin Walters 5879b96a64 jigdo V5: Use number of objects as cache invalidation trigger 
Changes in a server-side tree can cause the need for clients to import different
objects from packages. For example, turning on documentation. Another more
subtle case is where an object might "move" from package A to B by being deleted
from A - then the jigdo build process will pick the B version.

We need a "cache validation key"; a way for the server to tell the client that
the objects it should import from the package have changed. Initially I was
thinking of using the libostree "content hash" but that would be awkward as we'd
have to do an import on the server side too.

After more consideration I realized a simple *count* of the number of objects
actually works, because (as I note in a comment) changing a file in the tree
will result in it ending up in the jigdoRPM (and count as a deletion).  And
obviously adding or removing objects changes the count too.

In fact we could have done this *without* breaking the format by just having the
client start recording the number of xattr entries, but this adds greater
flexibility down the line since we can in theory change how we do cache
invalidation if we *really* need to (but at the cost of triggering clients to
redownload packages).

Note the client logic got moved around as now we need to parse all the xattrs
before we decide what packages to download.

My test case here is turning on docs - I noticed this actually affects *every*
package which was surprising to me; I expected at least some packages wouldn't
have docs. I'll double check this.

It'd be good to have a "moving object" case too which I may look at.

Closes: https://github.com/projectatomic/rpm-ostree/issues/1197

Closes: #1256
Approved by: jlebon
2018-02-16 18:45:51 +00:00
..
check Add support for rebase rojig:// 2018-02-02 20:18:58 +00:00
common Check and display pending security advisories 2018-02-15 15:30:26 +00:00
compose-tests jigdo V5: Use number of objects as cache invalidation trigger 2018-02-16 18:45:51 +00:00
composedata Fix "releasever" option, test it by default 2018-01-23 15:18:52 +00:00
ex-container-tests Fix "releasever" option, test it by default 2018-01-23 15:18:52 +00:00
gpghome daemon: start with one commit only when resolving versions 2016-12-24 12:28:48 +00:00
manual db: Remove query parameter to diff 2015-04-23 16:30:18 -04:00
utils Check and display pending security advisories 2018-02-15 15:30:26 +00:00
vmcheck jigdo V5: Use number of objects as cache invalidation trigger 2018-02-16 18:45:51 +00:00
compose tests/compose: Various fixes 2018-01-10 15:16:18 +00:00
ex-container Fix "releasever" option, test it by default 2018-01-23 15:18:52 +00:00
README.md tests: Add ./tests/compose 2016-12-06 19:05:05 +00:00

README.md

Tests are divided into three groups:

  • Tests in the check directory are non-destructive and uninstalled. Some of the tests require root privileges. Use make check to run these.

  • The composecheck tests 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 install inside 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 Makefile target because it doesn't require building and doesn't use uninstalled binaries.

  • Tests in the vmcheck directory are oriented around using Vagrant. Use make vmcheck to run them. See also HACKING.md in the top directory.

The common directory contains files used by multiple tests. The utils directory contains helper utilities required to run the tests.