mirror of
https://github.com/e107inc/e107.git
synced 2025-04-05 21:22:57 +02:00
3af03f1f5e
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.