Fixed irreversible data loss bug when preparing the app path repo
for tests
OLD BEHAVIOR
Remove untracked files from the working tree before and after
every test suite. The intention was to remove files that could
have been created by the tests, but this also removes all other
untracked files, including third-party plugins and themes.
NEW BEHAVIOR
There is now a triple locking mechanism protecting the state of
the app repository before tests are run so that after tests have
run, all file contents are restored to how they were before the
tests have run.
There are three locks, each guarding a different part of the
original repo:
* file
* commit
* stash
When the file lock is present, E107Base knows that any other file,
tracked, untracked, or ignored, was created by the tested code.
The file lock is checked into the commit lock, which saves all
tracked and untracked files in the form of a commit. This way,
uncommitted code can be tested without manually making a commit that
includes the untracked files.
The stash lock saves all ignored files in a Git stash. Ignored files
go in a stash instead of in the commit lock because they can be a
confounding variable affecting the outcome of tests. They are usually
user-configurable only and may not represent tested states.
When the saving is complete, E107Base will have access to tracked and
untracked files but not ignored files. The tests are run in this
configuration.
After each test suite runs, the repo is reset and cleaned to return
the files to the same state they were in before the test suite began.
Then, the locks are undone first by rolling back the commit lock,
which restores the originally uncommitted tracked and untracked
files. Next, the stash lock is popped, restoring the originally
ignored files. Finally, the file lock is removed, signifying that the
repo is back to its original data before the test suite was run.
In case of an ungraceful exit, at least one of the locks would be
left in the repo. The next time E107Base runs, locks are checked, and
if one or more are present, the repo is restored before the locks are
reestablished.
If the `git` command is inoperative, only the file lock is operative
and does nothing more than signify a test that is in progress or has
exited unexpectedly. Data protection is silently unenforced. This can
lead to unexpected tracked, untracked, and ignored file modifications
that will not be rolled back after a test suite has run.
Deployers, a concept unique to this repository, are now more separated
from Codeception modules.
This commit adds NoopDeployer, LocalDeployer, and SFTPDeployer to
address the three deployment target types in use by testers today.
The changes are backwards-incompatible because the structure of
config.sample.yml has changed, and all testers need to change their
config.yml or config.local.yml to continue testing. The reason for this
change is that the section "manual" no longer makes sense now that
Deployers are on a spectrum of automation levels.
The subsections under "manual" have been broken out into the root level.
The "db_dump" section has been merged into the new "db" root section.
There is a new "fs" root section used by the SFTP Deployer.
Other changes, enhancements, and bugfixes:
* cPanelDeployer no longer downgrades to "manual" mode when credentials
are missing or an unsupported component is requested. It now throws an
exception.
* Deployer::unlinkAppFile() was implemented for acceptance tests out of
necessity because the app requires a configuration file to be deleted
before re-running the app's installer.
* If a Deployer subclass does not implement the unlinkAppFile() method,
tests that depend on the method will be skipped gracefully.
* DeployerFactory now has a better autoload mechanism.
* A logical error in lib/config.php prevented missing nested array items
from using their default values.
* The Base Helper no longer pointlessly caches the DelayedDb module
* _bootstrap.php serializes the config.yml params into a global constant
so that the DeployerFactory can freely access the information.
- MOD: Renamed lib/deployers/cpanel_deployer.php to
lib/deployers/cPanelDeployer.php
- MOD: Moved responsibility of reconfiguring Codeception modules to the
deployers.
- NEW: Abstract class Deployer to standardize the interface to Deployers
- NEW: Acceptance tests now support unlinkE107ConfigFromTestEnvironment
- MOD: Removed null checks for the Deployer in the Base Module
- MOD: Improved public method naming in the Base Module
- MOD: DeployerFactory always returns a Deployer implementation now.
- MOD: InstallCest always clears out the e107_config.php file before
each test.
- MOD: Reduced code duplication in ./lib/config.php
- MOD: Replaced PHP 7.1 samples with PHP 7.2 samples in README.md
- NEW: ./config.sample.yml now supports customized database dumps, which
affects the Codeception database populator
- NEW: Code coverage reports now take into account the configured
`app_path`, which obviates a separate codeception.sample.yml file
and reduces the complexity in setting up this test harness
@CaMer0n and @SimSync: I'm aware that you previously needed a separate
codeception.yml file because the coverage reports didn't use the
`app_path` from `config.yml`. This has been fixed. I'd like to keep just
one place for custom configurations (config.yml) so that we can keep
tests reproducible and avoid inconsistencies if/when codeception.yml
gets updated in the future.
