This might require a change in the handlers where we tag the debug
"execstr" specifically so we can parse it correctly in the tests. For
now just ensure the handler runs without error.
The default system 'local' hosts the backupninja code and local backups
are done in that system. The vagrant user account on the 'remote' system
is made accessible by the root user in the 'local' system so that it may
accept ssh connections needed by the different handlers.
The sample data consists of default Drupal and Wordpress databases with
extra generated data using devel_generate (Drupal) and fakerpress
(WordPress). The content used by both modules is freely licensed.
This introduces support for setup_*, teardown_*, being_* and finish_*
functions in component tests. For example, when testing the sh handler
component in "sh.bats", this will invoke setup_sh and teardown_sh for
each test case, and begin_sh and finish_sh at the beginning of the first
test case and at the end of the last one.
- Depends on being run inside vagrant
- Installs dependencies automatically
- Environment is fully reset for each test
- Adds testcases for backupninja and sys handler
- Docs are missing but will be added
Two tests are currently failing due to two bugs, one of which has gone
unreported.
The code added in the previous commit is only relevant for the mirror
format. With the long format, directories are created correctly in the
rotation routine. For the short format, the directory is initially
created, but only for a local destination, so adding a short snippet to
the rotation routine does it.
Before it was only possible to backup root directories (depth one, eg.
/etc, /var, /usr, …). For example consider the following truncated toy
configuration for rsync:
[general]
mountpoint = /media/
backupdir = backup
[source]
include = /foo/bar
include = /etc
We assume you have prepared the existent but empty base-directory
/media/backup/ at your destination, then against the expectation, the
following error rises:
rsync: mkdir "/media/backup/foo/bar/" failed: No such file or directory (2)
The reason is that rsync will take the files from the folder /foo/bar/
and tries to put them into the ulitmate – and therefore existent –
destination /media/backup/foo/bar. This is not what you would expect,
since the prepared directory /media/backup exists and the application
should create the rest itself.
This Merge Request adds a little script which creates the required
directories in the destination before running rsync. It assumes that
the base-directory already exists, so that not too much directories
are created automatically (could be a mess if you accidentally type the
wrong path)
