testremote: Support testing readonly remotes with the --test-readonly option

This commit was sponsored by Ilya Shlyakhter on Patreon.
This commit is contained in:
Joey Hess 2019-01-17 12:39:29 -04:00
parent 8230b62e06
commit 8555169e71
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
4 changed files with 89 additions and 38 deletions

View file

@ -8,8 +8,8 @@ git annex testremote `remote`
# DESCRIPTION
This tests a remote by generating some random objects and sending them to
the remote, then redownloading them, removing them from the remote, etc.
This tests a remote by sending objects to it, downloading objects from it,
etc.
It's safe to run in an existing repository (the repository contents are
not altered), although it may perform expensive data transfers.
@ -20,7 +20,8 @@ the cleanup might fail, leaving test data in the remote.
Testing will use the remote's configuration, automatically varying
the chunk sizes, and with simple shared encryption disabled and enabled,
and exporttree disabled and enabled.
and exporttree disabled and enabled. If the remote is readonly, testing
is limited to checking various properties of downloading from it.
# OPTIONS
@ -28,9 +29,19 @@ and exporttree disabled and enabled.
Perform a smaller set of tests.
* `--test-readonly=file`
Normally, random objects are generated for the test and are sent to the
remote. When a readonly remote is being tested, that cannot be done,
and so you need to specify some annexed files to use in the testing,
using this option. Their content needs to be present in the readonly remote
being tested, and in the local repository.
This option can be repeated.
* `--size=NUnits`
Tune the base size of the generated objects. The default is 1MiB.
Tune the base size of generated objects. The default is 1MiB.
# SEE ALSO

View file

@ -1 +1,3 @@
It's not uncommon to create external special remotes for which, like for the built-in web remote, only download operations are defined. It would be good if git-annex-testremote had the option of testing such remotes, using as test data the keys and URLs already registered as present in the remote. This could also be used to test addurl-related functionality for fully implemented remotes; currently this part of a remote's implementation isn't tested.
> Good idea, [[done]] using the --test-readonly option. --[[Joey]]